Automatically create custom derived classes with e.g. closest

[daler]

from comments on https://gist.github.com/887065 :

hmm, it could also be incorporated into closest (and others):

rh = r.closest(h, d=True, keep_new=('name', 'dist'))

then you get the original bed + only 2 new columns. then have:

class Bed2(BedFeature):
    __slots__ = ('chr', 'name', 'start', 'stop', 'name2', 'dist')

and that class could be automatically generated inside closest. but that might be getting too complicated.

[brentp]

working on this now.

[brentp]

so we can do this, but you can't add slots declarations to a dynamically generated class, so we'd have to use another arbitrary name.

the other problem is that if you have a bed file, it might only contain 4 columns, but the slots dictionary has 12.

... having trouble thinking how to do it cleanly.

[daler]

'doh. i'll have to play with slots some more, i was hoping that sort of thing would be solved with a zip() stopping upon hitting the end of the shortest list (e.g., the 4 items).

does this help at all? (from http://docs.python.org/reference/datamodel.html#slots):

Without a dict variable, instances cannot be assigned new variables not listed in the slots definition. Attempts to assign to an unlisted variable name raises AttributeError. If dynamic assignment of new variables is desired, then add 'dict' to the sequence of strings in the slots declaration.

[brentp]

yeah, the problem is that you can't define the slots dynamically. so neither:

DynamicBed = type('DynamicBed', (BedFeature, ), dict(__slots__=['blah']))

nor:

def some_func(some_vars)
    class DynamicBed(BedFeature):
        __slots__ = some_vars

will work. because the slots are defined at, um, compile time. which makes sense, in retrospect... i left what i had at my work machine, i can check it in on monday.

[daler]

Ah now I see. It make sense now after seeing it written out like that.

Do you think it's worth having a DerivedFeature base class that acts similarly to Feature but doesn't have the speed of slots? Though I guess that would mean copying all the GFFFeature, BedFeature, etc code to the new DerivedGFFFeature, DerivedBedFeature etc . . . which would get ugly fast.

[brentp]

yes, i think that might work. i will (time allowing) prototype on monday. it wont take too long, just have to change init et al to use _dynamic_slots instead of slots

and it wont require copying all of them, only the Feature class will have an orthologous DynamicFeature... i think.

[daler]

cool. take your time, no rush.

[brentp]

so i put what i had for the start of this here: https://gist.github.com/890525

it's not working because of the slots stuff we mentioned above. and it's pretty ugly.
so then in closest(), it just has:

if 'keep_new' in kwargs:
    return self._keep_cols(tmp, other, kwargs['keep_new'])

but i think the way i have it set up is too complex--and fragile because it depends on the column numbers. any ideas?

[daler]

tricky . . . i'll have to think about this and fiddle around some more.

i agree, the column numbers seems easy to break, but then again that's what the "canonical" feature classes are using to parse a line into slots in the first place, so that part is prob fine.