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 have happened?
In the section titled "Alternatives to adding new operators", the
first alternative is to call a function to perform the calculation,
e.g. mul(a, b). The authors go on to list the disadvantages of this
approach:
Disadvantage:
- Prefix forms are cumbersome for composite formulas.
- Unfamiliar to the intended users.
- Too verbose for the intended users.
- Unable to use natural precedence rules.
All four of those boil down to "don't like the spelling". The
second one is disingenuous; if you're proposing six new operators,
the likes of which the world has never before seen, perhaps those
would also be "unfamiliar to the intended users"?
Although I would give 50:1 odds that we'd add these six operators to
Python, I'm simply not qualified to pass judgement. So I simply
nudge: /*someone*/ please come to a decision?
PEP 233: Python Online Help
http://www.python.org/dev/peps/pep-0233/
This proposes a new function in Python, "help()", which gives help
with Python objects, types, and areas of interest.
Gadzooks! We have this! In nearly this exact form! Since 2.2!
The only thing missing is the command-line form "python --help foo",
which you could achieve with "python -c 'help(foo)'". Heck, it even
has the pager support as Mr. Prescod suggests. Surely only a
clerical error has prevented this from being marked Accepted!
PEP 267: Optimized Access to Module Namespaces
http://www.python.org/dev/peps/pep-0267/
PEP 280: Optimizing access to globals
http://www.python.org/dev/peps/pep-0280/
These two PEPs propose new implementations of accessing module
attributes for CPython. The purpose of these new implementations
was strictly to increase performance; no new language semantics were
proposed. There was a third PEP addressing itself to the same
subject (PEP 266) but it was withdrawn.
We should either fish or cut bait. The newest of these proposals is
still seven years old. If this was a fruitful avenue of research, I
expect someone would have come to a conclusion. In the meantime the
Python dictobject has become the stuff of optimization legend.
Both of these PEPs would require new opcodes (e.g.
LOAD_GLOBAL_CELL). Would the speed gain be worth the heartburn we'd
inflict on all the other Python VM developers? Ultimately I suspect
we'll make global attribute access much faster through clever
JITting and caching (handwave handwave handwave) without needing
opcode support.
My quick perusal of these two PEPs doesn't qualify me to recommend
their Rejection or Withdrawl. Nevertheless I suspect that both PEPs
are dead, they just haven't noticed. I would welcome their authors'
consideration of this idea.
I hope you will be as gentle with your replies,
/larry/
--
http://mail.python.org/mailman/listinfo/python-list
