[Python-Dev] pep-dev

Paul Prescod paul@prescod.net
Sun, 23 Jul 2000 21:42:48 -0500

"Barry A. Warsaw" wrote:
> ...
> I'm beginning to think that our role on python-dev is different than
> we thought.  I think for a particular proposal for a new language
> feature, or core language functionality, it is our job to explore the
> details and ramifications as much as possible.  These should be
> summarized in a PEP, and it must have running code or a working patch.

This isn't directly a followup but you've touched on something I've been

I have been thinking for several days that PEPs give us a clear dividing
line between what could go on in Python-dev and what could go on in a
theoretical "other mailing list" with an open subscription. I called
this once "Python syntax" but instead we could call it pep-dev.

If we make a pep-dev mailing list where anyone could contribute then we
could have a lot more input from the Python community but the list could
still be focused enough that current python-dev'ers would feel like they
weren't wading through a million TKinter and curses questions.
Python-dev itself could be reserved for final implementation questions
once a feature has been accepted. 

Guido wouldn't need to read every message in PEP-dev because the whole
point is to come up with a PEP that he *could* read. In fact, nobody
would read every message of PEP-dev (well, maybe Thomas Wouters, he
seems to have infinite energy). Each message could be clearly labelled
as relating to this PEP or that one and if you aren't interested, you
could just ignore that thread. Messages that are not about a PEP would
be strongly frowned upon. 

Discussing curly-brace delimiters is fine -- as long as the end result
is a PEP that ensures that we never, ever have to discuss it again
because it clearly states all of the arguments for and against. (okay,
maybe I'm dreaming)

Even if you hate the features being proposed in PEPs, it seems really
useful to describe each of them once so that we have something to point
at and say: "Yeah, we've thought about it in detail and Guido decided
against it. Raising it again won't help." There are also some issues
that really should be worked out somewhere, like our standard package
hierarchy (if any) and the class hierarchy we will use after type/class
unification. And a formal definition of some of our implicit
interfaces...etc. etc.

 Paul Prescod - Not encumbered by corporate consensus
New from Computer Associates: "Software that can 'think', sold by 
marketers who choose not to."