Horrible Things I Regret Doing With Python Part One

Runtime Copy Paste With Global Variable Replacement.

"Could you make InlineAdmin in Django paginatable Joe?" Guido asked.
 I googled a while before regurgitating a Stackoverflow answer into Guido's lap.
"Oh cool, but we have multiple InlineAdmins, can you make it paginate for all of them?"
"Sure" I replied, "That'll just be a change to the admin class and some templates"

... Time passes

I had quickly changed the 'p' variable so it was dynamically determined by the model name assigned to the InlineAdmin class by adding a page_param property. The only problem was I that needed django's paginator_number template tag to take into account these new page variables as well.
from django.contrib.admin.views.main import (
    ALL_VAR, ORDER_VAR, PAGE_VAR, SEARCH_VAR,
)

...

@register.simple_tag
def paginator_number(cl, i):
    """
    Generates an individual page index link in a paginated list.
    """
    if i == DOT:
        return '... '
    elif i == cl.page_num:
        return format_html('<span class="this-page">{}</span> ', i + 1)
    else:
        return format_html('<a href="{}"{}>{}</a> ',
                           cl.get_query_string({PAGE_VAR: i}),
                           mark_safe(' class="end"' if i == cl.paginator.num_pages - 1 else ''),
i + 1)
The main problem being that PAGE_VAR is a global variable in paginator_number and I was trying as hard as possible to avoid copy pasting. I pondered for a while before writing out the code vomit in the next sample.

"Can you see what he's doing?" Tom called out, slightly exasperated as he looked at the hideous code I  had concocted. I cackled slightly as the other devs gathered around my desk, the faint glow of monitor lighting their faces. 
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
import copy
import types

from django.template import Library
from django.contrib.admin.templatetags.admin_list import (
    paginator_number,
    pagination
)

register = Library()


@register.simple_tag
def parameterized_paginator_number(cl, i):
    '''This ridiculous code makes a copy of paginator_number function
    The PAGE_VAR variable is global in paginator number, this function copies
    paginator_number and replaces the global PAGE_VAR with a page_param that
    we can set.
    '''
    # copy the globals of paginator_number
    func_globals_copy = copy.copy(paginator_number.__globals__)
    func_globals_copy['PAGE_VAR'] = cl.page_param

    paginator_number_func_copy = types.FunctionType(
        code=paginator_number.__code__,
        # pass our updated globals
        globals=func_globals_copy,
        name='parameterized_paginator_number',
        argdefs=paginator_number.__defaults__,
        closure=paginator_number.__closure__,
    )
return paginator_number_func_copy(cl, i)
"It's runtime copy pasting, what the hell is wrong with you?"

Here we use copy to make a copy of django's paginator_number's global (line 21). Then, in a horrible twist, we replace the PAGE_VAR in our new dict (line 22).

In line 24-31, we use the types library to create a new function. With exactly the same code as paginator_number, but crucially in line 27, we pass in our func_globals_copy, which contains the replaced PAGE_VAR global. Then we invoke our new paginator_number function copy and all is well.

Under the hood, each python function has a reference to a dict containing all the globals that the function uses, all we are doing is badly abusing this. #sorrynotsorry as they say.

"This is your fault django, you made me do this", I blurted out in some feeble attempt at an excuse following up with "I think it's less brittle than plain copy-pasting though".

"I actually agree." Tom said doing his best Patrick Stewart facepalm.

Popular posts

Digging into python memory issues in ckan with heapy

Image
So we had a report about a memory leak when using the ckan datastore extension, where large queries to the datastore would leak large amounts of memory per request. It wasn't simple to get to the bottom of it, at first I couldn't recreate it the leak at all. The test data I was using was the STAR experiment csv files, which I found when I googled 'Large example csv files'. The reporter Alice Heaton, had kindly written a script that would recreate the leak. Even with this, I could not recreate the problem, until I upped the number of rows fetched by a factor of ten. I suspect that Alice has more data per column with perhaps large text fields instead of the mainly numeric data of the STAR experiment data I was using. Once I could reliably recreate the problem, I ended up poking around using heapy , which I've used previously to track down similar problems and inserted some code to setup heapy and an ipdb breakpoint from guppy import hpy hp = hpy() heap ...
Read more

Randomising traitor numbers in Trouble in Terrorist Town

A while back a group of friends and I went through a spate of playing TTT(Trouble in Terrorist Town), to the point where we ended up playing during that Christmas day post dinner lull. For me, TTT scratches the traitor game mechanic that you can find in board games like The Resistance, Battlestar Galactica and Shadows Over Camelot which you don't really get in any other computer game. Unlike these games, the number of traitors is rigidly defined by the total number of players by a formula. local function GetTraitorCount (ply_count) -- get number of traitors: pct of players rounded down local traitor_count = math.floor (ply_count * GetConVar( "ttt_traitor_pct" ):GetFloat()) -- make sure there is at least 1 traitor traitor_count = math.Clamp(traitor_count, 1 , GetConVar( "ttt_traitor_max" ):GetInt()) return traitor_count end This means that for a given number of players, the number of traitors/innocents is the same each round. This i...
Read more

OpenMoonstone v0.2 released

Image
OpenMoonstone is a open source reimplementation of Moonstone: A Hard Day's Knight following along the lines of projects like OpenTTD and OpenXcom. You can try it out https://github.com/joetsoi/OpenMoonstone This release is a milestone as it contains the same number of features as the original demo that came out on the Amiga.  Why reimplement an old game? Fixing bugs Original OpenMoonstone v0.2 Enemies always face the player in Moonstone, in the original this meant that for the AI controlled knights, the distance the knight would move was out of sync with the animation causing a "jumpy" animation. Adding New Features I've added the ability for four players to fight at once. The amiga only had two controller ports so was restricted to two players, as a child I always wanted a three way battle with my brothers and adding additional entities in an ECS is easy once it's all set up. As a side project It's hard to stay motivated when worki...
Read more