[Python-3000] Generic function PEP won't make it in time
Phillip J. Eby
pje at telecommunity.com
Mon Apr 23 06:09:57 CEST 2007
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.)
More information about the Python-3000
mailing list