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

[Guido van Rossum]

While you're at it, could you also add a pointer to this patch as a
sample implementation?

http://python.org/sf/1681101

It's far from complete at this point; so far, I've got the syntax
working and it seems to compile old code just fine, but the keyword
args and */** notation are simply ignored. If someone wants to work on
this, drop me a note to see if I haven't made progress already.

--Guido

On 3/14/07, Talin <talin at acm.org> wrote:
> 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
>


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