That's okay. We won't be able to consider GFs for 3.0a1, but the whole library reorg thing will be done later, so I expect adding GFs later (to the library) will also be okay. I do hope that you'll stay with us while I barrel forward with the ABC PEP. I see no serious incompatibilities between GFs and ABCs, so I don't believe I should hold it up just because your proposal is late; but there is time to tweak the details to avoid gratuitous friction between the two mechanisms.
--Guido On 4/22/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > I got off to a good start in terms of figuring out what needs to be in the > PEP... good enough to realize that a complete specification of what I have > in mind is probably going to dwarf the WSGI spec. There are just too many > details that have to be explained; the roughly 1000 lines of Python code I > have in mind is translating to quite a *lot* more words of English, to > explain intentions, ramifications, etc. > > In particular, when you implement generic functions using generic > functions, it reads a lot like trying to explain the relationships between > "type" and "object" (i.e. type being its own type and an instance of > object, and object being a subclass of type). You can say what needs to be > said in a fairly short space, but saying it in a way that lets people > actually wrap their heads around it takes a bit more text. :) > > So, there is no way I could get it done in time for anybody to *read* it > before the deadline, let alone discuss it (and there are at least a few > things about it I think would really *need* some discussion before > finalizing the proposal). > > On the plus side, it was interesting to think through how I'd take the > current peak.rules.core and adapt it to Python 3.0, with argument > annotations and no classic classes to worry about. It was also interesting > to look at how certain things might overlap with other Py3K PEP's; for > example, the peak.rules.core API has an '@abstract' decorator that's used > in basically the same way as '@abstractmethod'... except that you can add > overloads to an @abstract function. (Functions not declared @abstract are > considered to be a 1-method generic function whose default rule is the > function's original body code.) > > Anyway, I'm not abandoning the idea, but it's beginning to seem to me that > it might be a lot easier to close the open issues by actually working on an > implementation instead of first trying to write an adequate explanation of > what the issues are. > > However, I was *definitely* being delusional about how much time it would > take to write this up -- probably because how to make systems like this is > now so deeply embedded in my subconscious that I don't think about it much > any more. Like "type" and "object", it's all very simple... until you try > to explain it. :) > > (It occurs to me that I should mention that, just like the relationship > between 'type' and 'object' rarely matters unless you delve into > metaclasses or other wizardry, so too am I referring here only to the > wizard-level aspects of a generic function module, where my design allows > for people to write their own dispatchers or interface implementations and > plug them into the base module, using the same decorators and basic > machinery. Merely *using* generic functions and interfaces would of course > be at least as simple as interfaces and static overloads in Java or C++ -- > that's *not* the part of the PEP that's hard to write.) > > _______________________________________________ > Python-3000 mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-3000 > Unsubscribe: > http://mail.python.org/mailman/options/python-3000/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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
