[Python-3000] Discussions with no PEPs

[Talin]

Guido van Rossum wrote:
> I don't think a consensus has been reached on any of these.
> 
> My votes:
> 
> - generic functions: no
> - interfaces: no, but I'd like to work on ABCs instead
> - metaclass syntax: I'd like to see your PEP

I've gone back and read all of the threads on Metaclasses, and here is 
the current state of affairs:

There are really two separate issues.

First, there is a purely cosmetic argument about how metaclasses ought 
to be specified syntactically, which I won't go into in any detail. Most 
of the proposals centered around what I will call 'Class Definition 
Keyword Arguments' (CDKA), in other words keyword arguments that are 
passed in along with the list of base classes.

Secondly, there is the desire to allow the metaclass to get involved 
earlier in the class construction process, allowing the metaclass to 
customize classes in ways that are more fundamental than what we can do 
today.

The primary method for achieving this was envisioned to be a means to 
supply a custom, dictionary-like object that would be used to collect 
the class member definitions as the class was being evaluated. However, 
there was a great deal of controversy as to how that custom dictionary 
should itself come into existence.

The first idea was that the metaclass should have some method for 
constructing the dictionary, which it would later receive after it was 
filled in with all of the class methods. One drawback to this approach 
was that it required a metaclass to be invoked twice, once to create the 
dictionary, and once to use that dictionary to create the class object. 
This required that the metaclass actually be a class, as opposed to the 
current state of affairs where a metaclass can be any callable.

Some people felt that these two operations (creating the custom 
dictionary and invoking the metaclass) should be specified 
independently; However, since the design of the metaclass and the design 
of the dictionary will normally be tightly coupled, it makes no sense to 
require the user of the metaclass to specify both halves separately.

Now, it was pointed out that the only use cases for a custom dictionary 
that anyone could think of were all about preserving the ordering of 
declarations. In other words, although a large number of use cases could 
be generated (C structs, COM objects, ORBs, IDLs, etc.) all of them had 
to do with interfacing to external systems that operated using an 
implicit ordering of fields.

So the suggestion was made that instead of having the metaclass create a 
custom dictionary, simply *always* use a special 'order-preserving' 
dictionary when defining a class. In other words, there would be a 
subclass (or more likely, wrapper) of dict that kept a record of the 
insertion order of items, which would be retrieved via an itemorder() 
method or such. The built-in class construction code would use this 
special subclass of dict whenever it created a class, and any metaclass 
that was interested in knowing the order of definitions could find out. 
I'm also assuming that, for performance reasons, the order-preserving 
dict is not required to eliminate duplicates if a key is inserted 
multiple times; It's up to the metaclass to sort all that out, which in 
most cases will be trivial.

With this scheme, there is no longer any need to change the syntax of 
metaclasses, although there may be other reasons for doing so.

Unfortunately, this solution has two drawbacks. First, the 
order-preserving dict will be slightly slower than a regular dict, which 
in turn will cause a slight slowdown for the creation of all classes. 
Perhaps this could be turned off if there's no metaclass declared.

Secondly, I believe that it is often the case where the dictionary that 
is used to collect the member definitions (before the metaclass is 
invoked) is the same as the one that is used to hold the class members 
after the metaclass is finished. At this point, you would want some way 
to disable the recording of insertions, otherwise each time you modified 
a class member you would be extending this record of insertions.

I think there are enough open issues here that it will require 
discussion; The question is, what is the proper place for the discussion 
to take place.

-- Talin