Sorry, if my Italian is non-existent. Code is code however. Could you verify that the article covers:
1. Complaints that __metaclass__ will be silently ignored in PEP 3115. My understanding from the last line of the Rational section is that this is undecided. 2. Complaints that, without _prepare_, the __new__ operation will not know which order the items were declared, and that everyone will write ordered hash implementations. Though I propose that an array exist for the time analogous to the current __new__ redirect. One can look at the array as a hash with very poor performance characteristics. This should be acceptable for the analogue. After type.__init__() is actually called, only a hash would survive. 3. The metaclass can add additional class functions to support class addition for on the fly creation of mixed in classes. Though one could simply add these functions into the namespace during the __new__ analogue. My understanding is that type.__new__() will not add new implementations if they exist in the namespace. I may well be wrong about type.__new__(), so please verify this yourself. You have a legitimate counter-argument that grouping the implementations of __add__ in the metaclass is cleaner than having them stand alone and be referenced in. Is this your argument? Lost, Charles On Jan 13, 2008 9:58 AM, Michele Simionato <[EMAIL PROTECTED]> wrote: > > On Jan 13, 2008 9:37 AM, Charles Merriam <[EMAIL PROTECTED]> wrote: > > > Well, I'm explicitly dropping this. So far no one has pointed out > > > any use cases that are not equivalent to intercepting an array of the > > > namespace in the __init__() of a subclass of type, then calling > > > type's __init__() on the modified namespace. > > There are many use cases. For instance in > http://stacktrace.it/articoli/2008/01/metaclassi-python-3000/ > I discuss operator overloading on records. The paper is in Italian, > but you can just look at > the code and at the examples. > > Michele Simionato > _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
