[Bf-python] Ipo/IpoCurve API revisited

Ken Hughes khughes at pacific.edu
Fri Mar 24 18:53:29 CET 2006


Ken Hughes wrote:
> Toni Alatalo wrote:
> 
>> On Saturday 11 March 2006 23:33, Ken Hughes wrote:
>>
>>> the direction that the API rewrite was taking (which apparently for now
>>
>>
>> we talked about this a bit with Ken and Jestie on irc - revisiting 
>> many issues that were talked on this list last year etc. i try to 
>> summarize here a bit.
>>
>>>> (read-only).  Makes it possible to do "ipo['LocX']" or "ipo[Ipo.LocX]";
>>>> something like ipocurve[framenum] to do current .evaluate(framenum) 
>>>> might
>>
>>
>> again i remembered that someone said that obipo.loc_x would be nicer 
>> than obipo.['LocX'] for that and i think i agree.. (classes in py are 
>> just syntactic sugar on dicts anyway, like the perl ppl say :)
>>
>> how does this seem to you? just an idea..
>> obipo #a object ipo
>> obipo.LocX #LocX ipo: ipocu if that channel exists in this block, None 
>> if not 
> 
> 
> After thinking about this, I don't know if this will work with tp_getset 
> (or at least not easily).  I'm trying to interpret PEP 252 but it seems 
> that "__slots__" might allow per-instance attributes, if only I can 
> figure out how to implement them.

A follow-up:  after not being able to figure out how to do this, posting 
on usenet with no replies and asking on #python without responses, I 
can't see how to make this work without a new class for each Ipo type 
(Object, Material, etc), which seems like overkill.  I was able to add 
new attributes to an instance, but they are only stored in a local dict 
which don't call tp_getset handlers, so unless there was some explicit 
ipo.update() call they wouldn't have any effect.

So unless someone comes up with a suggestion, I'm going to (have to) 
stick with the ipo['LocX'] approach.  Again, I can implement this if we 
  don't go with tp_getset for the Ipo module, but that raises a 
different issue (and I'm OK with going that route if we agree ipo.loc_x 
is the more desirable route).

Ken



More information about the Bf-python mailing list