Why "from __future__" stinks; a counter-offer

[Tim Peters]

[John W. Baxter]
> For the future, the time to complain about PEP contents is when the PEP
> is posted, not after it has been posted, discussed, implemented, and the
> result distributed.
>
> For the Python 2.1 batch, late rants seem excusable, since the process
> is new.

The future_statement PEP also came very late in the release process:  like
the "Import on Case-Insensitive Filesystems" PEP, it was written to address a
problem that didn't become apparent before an alpha release was already out
the door, and was darned-near a retroactive PEP.  I certainly hope that, in
the future, all PEPs get more lead time than these did.

[Tim Rowe]
> But there's part of the problem; egoless PEP writing is as hard as
> egoless programming, and having come up with a solution the author of
> that solution is bound to have some emotional involvement in that
> solution.

Sure, although in this particular case my emotional involvement doesn't
extend much deeper than the nesting of Python 2.0's namespaces <wink>.

> There have been (rightly IMHO) howls of protest about __future__,

Howls are rarely productive.

> but Tim has said it's ok for him, routinely dismisses all protests,
> presumably because he genuinely doesn't understand what our problem is,

Fine, so I'm an idiot:  write a PEP that explains your version of the
self-evident truths for the benefit of those I haven't paid off <wink>.

> and he tells us it's going in anyway.

That part is just spelling out a consequence of how the *process* works:
without an alternative, what do you expect?  That it *won't* go in?  Get
real.  2.1 *needs* a mechanism to deal with the incompatible nested-scopes
change (or at least Guido was convinced by those who said it did).  So we do
this; wait for an alternative PEP nobody shows any sign of intending to write
(I sure asked Martin to write up his "directive" alternative often enough,
and that was the only alternative I saw that was close to being thought out);
throw away the nested-scopes change; or delay 2.1 indefinitely.  Deciding
among those wasn't my call, but I believe that going with the
future_statement was the best of those options.  More importantly, Guido
believed that.

> Can you see why we're not all convinced that the PEP process is any
> help to us?

It isn't a goal of the PEP process that everybody get what they want, or even
that everybody get something they'll accept under protest.  ANSI and ISO
committees work that way (via (often grudging) consensus), but Python does
not.  The best way to oppose a PEP is to write a competing PEP.  The entire
process would work much better that way:  Guido has no qualms about picking
winners and losers, and if you think your views are being ignored, belittled,
or misunderstood, you're encouraged to write them up yourself.  Writing a PEP
is as easy as we could make it -- although, granted, nothing will ever be as
easy as posting complaints to Usenet <0.7 wink>.

win-lose-or-draw-they're-all-possible-outcomes-ly y'rs  - tim