[Python-3000] Metaclasses in Python 3000: Draft 2

[Talin]

Guido van Rossum wrote:
> On 3/14/07, Talin <talin at acm.org> wrote:
>> PEP: xxx
>> Title: Metaclasses in Python 3000
> 
> Checked in as PEP 3115. I fixed the two typos that were noted so far
> (missing comma and inconsistency in name of first arg to __prepare__;
> I renamed the latter metacls) and cleaned up one case of extra
> whitespace (.append( key ) -> .append(key)). Now on to the content:
> 
>>     def prepare_class(name, *bases, metaclass=type, **kwargs):
>>        prepare = getattr(metaclass, '__prepare__', None)
>>        if prepare is not None:
>>           return prepare(name, bases, **kwargs)
>>        else:
>>           return dict()
> 
> This is missing the extraction of the metaclass default from the
> bases. It's probably okay to default metaclass to None and add this
> code to the body:
> 
>  if metaclass is None:
>    metaclass = compute_default_metaclass(bases)
> 
>>     type. It does not need to implement the full dictionary interface;
>>     only the ability to insert items and retrieve them are
>>     required. (Note: double check that this is true).
> 
> As was mentioned, getitem, setitem and delitem are used. No other APIs
> are, unless the dict is accessed via locals(), or unless dir() is
> used. IMO it's up to the prepare function to provide the features that
> it wants to support; if it doesn't want to support deletions, that is
> between the metaclass and the users; the language spec doesn't have to
> say anything about this.
> 
>>         # The custom dictionary
>>         class member_table(dict):
>>            def __init__(self):
> 
> <style-nit> Despite this just being an example, I'd like for the
> member_table class to be defined outside the OrderedClass class. it
> also probably ought to have a conforming name, i.e. MemberTable.
> </style-nit>
> 
>>     Another good suggestion was to simply use an ordered dict for all
>>     classes, and skip the whole 'custom dict' mechanism. This was based
>>     on the observation that most use cases for a custom dict were for
>>     the purposes of preserving order information. However, this idea has
>>     two drawbacks, first because it means that an ordered dict
>>     implementation would have to be added to the set of built-in types
>>     in Python, and second because it would impose a slight speed (and
>>     complexity) penalty on all class declarations.
> 
> I think this rebuttal isn't strong enough; I'm sure there *will* be
> use cases where a custom prepare method can solve a problem that a
> standard ordered dict couldn't.

This all looks good to me - I think I still have permission to check in 
changes to the PEPs dir, want me to go ahead and make the changes directly?

-- Talin