Cleaning out the cobwebs in the PEP cupboard

[Larry Hastings]

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/