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 _______________________________________________ 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
