Order in metaclass

[Carlos Ribeiro]

On Wed, 13 Oct 2004 21:35:47 GMT, Bengt Richter <bokr at oz.net> wrote:
> >Hey, I came first with that a couple of weeks ago :-) but in truth, it
> >was Alex Martelli that pointed to me that a metaclass function would
> >work... but not only is it not recommended, it's also said to make
> >Guido shudder ;-) Seriously, although it works, it's not recommended
> >practice. Metaclasses are supposed to be classes, not functions.
> >
> IIRC it was Guido himself who let the cat out of the bag about a function, in
> some early metaclass notes. But maybe I don't RC ;-)

Alex said that he was the one that shown it to Guido, but even he
couldn't recollect it very well. But that's not the point anyway.
 
> >class Foo:
> >    a,b,c = myfunc(...)
> >
> That one _will_ show a,b,c in order. They're all visible to the compiler as names.

Sure. I misunderstand your trick, and assumed you did similar to what
I did. Your trick is _much_ better than my original one. But still, it
can be fooled, as Peter has shown in another message; but OTOH, it
doesn't _require_ all names to be subclasses of some OrderedAttribute
class.

I'm now thinking about how to use your trick, maybe combined with
mine, into the same framework. I'll let you know if I managed to make
it.
 
> >Of course, we are now getting into corner cases that show how much are
> >we pushing class  statements in Python. The _sane_ way to make it all
> >work would be to have a hook to provide a user-defined dict to the
> >class locals() dir; aternatively, the natice dict() could provide a
> Interestingly, you can pass a dict subtype instance as the last arg to type, but
> it seems just to grab the instance's base dict. I.e., you apparently can't
> get the subtype instance back as .__dict__. Oh well ;-)
 
I don't get it; would you mind to explain it better? Did you test it?

> >ordered interface (but then it wouldn't be a simple hash mapping, a
> >more complex structure such as a tree would be needed). Both are far
> >from happening in Python 2.x, IMHO... and I really doubt if dicts will
> >ever be changed to accomodate ordering, even in Python 3.0. Too much
> >hassle for too little gain. A hook function seems to be more sensible.
>     class C(object, cdict=myDict): pass ??
 
My best bet is something like metaclasses implemented as class
decorators -- something that is read by the compiler _before_ the
class statement is executed. Being a class (not a function), it could
provide methods to customize some aspects of the class statement
execution; for example, a __getlocals__() method, or something along
these lines. and, of course, it would be able to put the __metaclass__
name right into the locals() dict, which would make it backward
compatible. The problem is, function decorators are only executed
_after_ the function def is executed; and having class decorators work
differently is a big no-no.

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: carribeiro at gmail.com
mail: carribeiro at yahoo.com