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 <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > On 3/14/07, Talin <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
