"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 thinking. 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."
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4