[Bf-committers] registering 'dynamically generated' ops?

Bassam Kurdali bkurdali at freefactory.org
Tue Sep 14 00:44:01 CEST 2010


Hi Martin,
> 
> 
> --- On Mon, 9/13/10, Bassam Kurdali <bkurdali at freefactory.org> wrote:
> 
> > Final solution:
> > It seems that using setattr() to set the invoke / execute /
> > poll
> > functions was the culprit, presumably metaclassing works
> > *first, then
> > setting the functions, so the operator doesn't end up
> > working.
> 
> Yes, that would be exactly it. A metaclass is used when instantiating
> the type of the class, so adding attributes or methods afterwards is too
> late.
> 
> > I think it might be a bit nasty that setattr() and type()?
> > no longer
> > work as expected, since people with a python background
> > expect these to work.
> 
> Frankly, I find modifying a class after definition a bit nasty too,
> especially when metaclasses are involved (the resulting object might not
> even be a class, for all you know).
> 
> > Also a bit nasty is the difference I mentioned in my
> > original mail
> > between Win7 and Linux; it seems odd (and unfortunate) that
> > in win7 I
> > need to just register the operators, whereas in Linux I
> > need to
> > unregister and then re-register again. 
> 
> Is that still present after the fix?
No, after the fix metaclassing works as expected. But, should somebody for something need setattr, they're going to run into the platform problem. I'm personally happier with my code right now, it seems more readable without using type() and setattr(). 
> 
> That is indeed strange behavior as I don't think there's anything in the
> registration code that is platform specific.
> 
> Martin
> 
> 
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers



More information about the Bf-committers mailing list