Order in metaclass

[Bengt Richter]

On Wed, 13 Oct 2004 18:56:32 -0300, Carlos Ribeiro <carribeiro at gmail.com> wrote:
[...]
>
>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.
I doubt if it's a good idea to be dependent on such implementation details,
except to make throwaway prototypes of functionality with what's available.
> 
>> >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?
I just did an experiment:

 >>> class CD(dict):
 ...     def __repr__(self): return '<CD %s>'%dict.__repr__(self)
 ...
 >>> cd = CD(some='content')
 >>> cd
 <CD {'some': 'content'}>
 >>> T = type('T',(),cd)
 >>> T.some
 'content'
 >>> t=T()
 >>> t.some
 'content'
 >>> T.__dict__
 <dictproxy object at 0x00901090>

... not <CD {'some': 'content', ...}> in any form, AFAICS. I.e., it acts like
I just did T = type('T',(), {'some':'content')}

IOW, I think type must just extract the contents from the supplied dict or dict subtype.
I wonder what method one should override to customize the content extraction, or if that's possible.

So T.__dict__ seems to be a new container with its own dict methods...
 >>> T.__dict__.items()
 [('__dict__', <attribute '__dict__' of 'T' objects>), ('__weakref__', <attribute '__weakref__' o
 f 'T' objects>), ('__module__', '__main__'), ('some', 'content'), ('__doc__', None)]
 >>> T.__dict__.__class__
 <type 'dictproxy'>


>
>> >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.
>
ISTM a metaclass is a lot like a decorator for classes. I.e., it is called
just after the class definition executes and before the name is bound.

They are both somewhat like atexit hooked functions. Except that the process
is not an OS process, but just a little segment of the current thread having to
do with building a class. If you looked at it in an OO way, you might have
an object that you instantiate and set up before kicking off its run method.
Then you could have properties that acccumulated chains of decorator functions
to do between the default construct and bind operations, but you could also
have other property/hooks to add e.g., pre-processing of the arg list being
passed to the constructor, and properties to hold alternate components such
as dicts etc. IOW, a big factory object with lots of knobs that ultimately
produces some custom thing. There ought to be some unified concept behind
this process IMO, whether the thing produced is a function or class or type.
They are all factories that compile and pull together pieces and glue or bolt
them together. The tough part is to make it fast with pre-glued assemblies
and yet allow custom bolting together of custom components.
Well, metaphors can only be ridden so far ;-)

Regards,
Bengt Richter