[Python-3000] Metaclasses in Py3K
talin at acm.org
Sat Dec 16 21:32:05 CET 2006
Josiah Carlson wrote:
> Talin <talin at acm.org> wrote:
>> There's also Josiah Carlson's proposal which separates the 'metaclass'
>> function into two parts, the 'dict creation part' and the 'class
>> finishing part'. (I.e. type= and dict=.) I would rather see them
>> unified, as it makes the class declaration syntax simpler, and it's easy
>> enough to write a metaclass that does one or the other or both.
> The reason I offered a mechanism for separating them was because I don't
> particularly like the idea of hitting the metaclass twice (particularly
> a staticmethod, or base type assignment, which is just one more line of
> code for people to forget, and makes metaclass/dictionary reuse more
> restrictive), and because metaclasses, so far, haven't needed to be
> classes. This particular proposal would make it so that metaclasses
> would either need to be a class, or would need to assign to an attribute
> on the function metaclass in order to overload the dictionary semantics.
> Seems to be an unnecessary requirement.
Most of the time, the only reason for adding a custom dict is so that
the metaclass can post-process it. The most common use case that I can
think of is a dict that remembers the order in which things were
defined; This by itself is not useful unless there's a metaclass that
can take advantage of that ordering information.
So in other words, I don't see the two as independent at all. Yes,
technically they might be, but in terms of how metaclasses get used in
practice, I don't think they will be separate, and thus we're exposing
an unnecessary implementation detail and making class declarations more
cluttered than needed, in order to preserve a distinction that most
users won't care about.
> Of course, then we still have __slots__. Will the madness never end?
I believe that with this new system, we'll eventually be able to
eliminate the need for __slots__. The metaclass can examine the
dictionary and create a '__slots__' member based on the decorators or
wrappers of the various values within the dict.
>> 4) Backwards compatibility
>> It might be possible to retain backwards compatibility if desired. In
>> the proposed scheme, the metaclass is invoked twice - once to create the
>> dictionary, and once to 'finish' the class. Note that the second step is
>> identical to the operation of the current __metaclass__ feature.
> Any syntax-based scheme is, by definition, not fully backwards
> compatible. The best we can hope for is for new functionality to not
> work as intended in previous Pythons, but still be runnable.
No, I'm talking about allowing the old __metaclass__ syntax to still
continue work in the new versions of Python. It won't have all the
functionality of the new syntax, but it will still work as it did before
- at least, until we decide to remove it.
More information about the Python-3000