Writing PEPs (was Re: Why "from __future__" stinks; a counter-offer)

[Aahz Maruch]

In article <995pl4$jta$1 at news.mathworks.com>,
Joshua Marshall  <jmarshal at mathworks.com> wrote:
>
>As responses to suggestions, there's a lot of "write up a PEP or it
>won't get implemented" going around.  I can understand this, but it's
>also important that good ideas don't go to waste just because the
>proposer _didn't_ write a PEP.
>
>I guess I just hope that the PEP-mechanism doesn't make it so that
>good proposals get overlooked in favor of proposals with enthusiastic
>proponents.

Why?  BDFL checks off on *all* PEPs.  Thus the worst case scenario (e.g.
"print >>" ;-) is that a proposal has enthusiastic proponents *and* is
good enough to satisfy Guido.  I can understand the angst over
__future__ because it popped up in the middle of the alpha cycle with no
time to sit down and chew it over (I felt/feel the same way about the
"print >>" mess), but in this case there's the mitigating factor that
not doing __future__ would have meant one of two things, neither of
which was going to happen for 2.1:

* Completely punting on nested scopes until at least 2.2
* Leaving nested scopes as-is, with concommitant code breakage

I'm still not all that happy with __future__, but I think it was the
best decision in the time available.  (Delaying 2.1 for a month or two
*just* because of nested scopes didn't/doesn't make sense, either.)
-- 
                      --- Aahz  <*>  (Copyright 2001 by aahz at pobox.com)

Androgynous poly kinky vanilla queer het Pythonista   http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6

There's a difference between a person who gets shit zie doesn't deserve
and a person who gets more shit than zie deserves.  --Aahz