[Python-3000] Generic function PEP won't make it in time

[Guido van Rossum]

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 <pje at telecommunity.com> 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
> Python-3000 at python.org
> 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/)