[Python-3000] PEP 3124 - Overloading, Generic Functions, Interfaces, etc.
tjreedy at udel.edu
Thu May 10 20:11:56 CEST 2007
"Phillip J. Eby" <pje at telecommunity.com> wrote in message
news:20070510155756.2DEB73A4061 at sparrow.telecommunity.com...
| At 08:43 PM 5/9/2007 -0600, Steven Bethard wrote:
| Yeah, and the dilemma is that if I go back and add in all the
| examples and clarifications that have come up in these threads, it's
| going to be even bigger. Ditto for when I actually document the
| extension API part. The PEP is already 50% larger (in text line
| count) than the implementation of most of its features! (And the
| implementation already includes a bunch of the extension API.)
| I'm certainly open to suggestions as to how best to proceed; I just
| don't see how, for example, to explain the PEP's interfaces without
| reference to generic functions. So, even if it was split into
| different documents, you'd still have to read them in much the same
| order as in the one large document.
Without having read the PEP itself (yet), as opposed to numerous posts
here, I would note that many PEPs are shortened by referencing other docs.
(The class decorater pep being an extreme example.) This makes easier to
get an 'executive overview' of the proposal is one is not interested in the
details. I will try to take a look in the next week.
| By the way, I have gotten off-list notes of encouragement from a
| number of people who've said they hope the PEP makes it, so evidently
| it's not overwhelming to everyone. Unfortunately, it seems to be
| suffering a bit from Usenet Nod Syndrome among the people who are in
| favor of it.
I don't see an immediate personal use for either ABCs or your generic
function machinery. But to me, GFs seem at least as much in the spirit of
Python as ABCs. So here is a public probably yes nod from me;-)
Terry Jan Reedy
More information about the Python-3000