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