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

[Guido van Rossum]

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.

On 3/14/07, Steven Bethard <steven.bethard at gmail.com> wrote:
> Perhaps __prepare__ should be special-cased like __new__ so that it's
> always a @classmethod?

No, I don't think __prepare__ should get special treatment. (And
__new__ is a static method anyway, not a class method.)

All in all, I think the PEP is on the fast track to acceptance. Thanks, Talin!

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)