There are some PEPs that seem to be stuck in a perpetual limbo, never to
be decided upon. Some of them seem hopelessly antiquated now--they were
proposed long ago and the language has moved on. With every passing day
it becomes less likely they will ever be Accepted.
On the off chance that their fate is decided and we just hadn't noticed,
I thought I'd take a couple of minutes, talk about some of those PEPs,
and make some suggestions. I fear I am jamming multiple feet into my
mouth; honest, I mean no harm. Just trying to get the wheels of fate
turning once again.
We start with one I think is terribly obvious.
PEP 333: Python Web Server Gateway Interface v1.0
http://www.python.org/dev/peps/pep-0333/
The WSGI PEP. Even though it's six years old, and mighty empires
have been built upon its rock-solid foundations, it's still marked
as Draft.
This is sillier than Gmail still being marked beta. In the name
of Guido's shiny time machine: could PEP 333 please be formally
Accepted?
The rest of these are marked deferred, and date from very early in the
decade, sometimes even before Python 2.0.
PEP 211: Adding A New Outer Product Operator
http://www.python.org/dev/peps/pep-0211/
This proposes @ as a product operator for iteration. It would
make for i, j in S @ T: equivalent to for i in S: for j in T:.
Since then we've added generator expressions and itertools. In
particular, itertools.product (added in 2.3) solves exactly the
problem described, and as it's in C it wouldn't be any faster if
this were an operator. The only debate left is whether this is
important enough to warrant the shorter spelling. If brevity is
that important, do from itertools import product as p. That would
add a net of two extra characters per iteration. I therefore gently
suggest that this PEP be Rejected (or Withdrawn).
PEP 212: Loop counter iteration
http://www.python.org/dev/peps/pep-0212/
This PEP attempts to solve two problems: for i in range(len(x)): e
= x[i] is inconvenient and wordy, and for i in range(len(x)): is
wordy. It proposes either a new keyword (indexing), two global
functions (irange and indices respectively for the two problems),
and/or two method calls on sequences mirroring the proposed global
functions.
The former problem was addressed with enumerate (added in 2.3, see
PEP 279). The latter problem is not severe or common enough to
really need addressing. Certainly it doesn't merit a keyword or a
new method on every iterable; I don't think it even merits a global
function. The right place for this function, if we want it at all,
would be in itertools. I therefore gently suggest that this PEP
also be Rejected (or Withdrawn).
PEP 213: Attribute Access Handlers
http://www.python.org/dev/peps/pep-0213/
This proposes an extension to classes to allow overriding access to
members on a case-by-case basis. Instead of writing one big
__getattr__, you could write individual methods called __attr_XXX__
to override behavior on self.XXX.
In other words: properties. This was years before Python 2.2 and
the mighty PEP 252 which introduced properties. Properties solves
this exact problem. This PEP actually discusses 252 at the end,
staring its own fate in the eye. While I admire its courage, there
is no chance of this PEP being Accepted. Once again I must
recommend Rejection (or Withdrawl).
PEP 222: Web Library Enhancements
http://www.python.org/dev/peps/pep-0222/
This is an open-ended we should make Python library support for CGI
better proposal. It is not terribly specific; it seems to have
been proposed in a deferred state. Back before 2.1.
Since then, CGI has fallen by the wayside; no serious server-side
developer would willingly incur a new process per request. We also
have the aforementioned WSGI, which addresses the only specific area
of the proposal (the Request and Response objects).
In any case I suggest that this is not the proper way to approach
this topic. Instead, someone / some folks should /write/ such a
module, release it on the 'net, get lots of happy users, and /then/
propose submitting it to the standard library. Therefore this PEP
should be Rejected (or Withdrawn).
PEP 225: Elementwise/Objectwise Operators
http://www.python.org/dev/peps/pep-0225/
This proposes six new binary operators: ~+ ~- ~* ~/ ~% and ~**, and
six new augmented assignment operators (add = to the end of the
previous six). These would be used for numeric expressions to
differentiate between elementwise operations (operate on individual
elements of the two operands) and objectwise operations (operate on
each of the two operands as a whole).
My math isn't good enough to say how necessary this is. But it's
been more than eight years since it was proposed; if it was that
necessary surely more would
