pep 308: why doing (almost) nothing suffices

[Edward K. Ream]

"It was a stark and iffy plight; the email fell in torrents--except at
occasional intervals, when it was checked by a peppy gust from Guido (for it
is on comp.lang.python that our scene lies), rattling along the syntax, and
fiercely agitating the scanty flame of facts that struggled against the dark
competing opinions."

My apologies for the timing of this.  I haven't yet figured out how to
encourage bathtub insights.  Taking more baths doesn't seem to help ;-)

Reading Guido's summary of pep 308 at
http://www.python.org/peps/pep-0308.html I am struck by:

a) Guido's thoroughness and fairness and
b) by the sense that none of the alternatives are very good.

Indeed, if any of the alternatives was actually good (rather than just
better than the rest) the choice would have been easy.

Whenever I have been faced with a similar situation I try to do something
"completely different" that solves the problem from a different direction.
I have had several ideas for something completely different regarding 308,
and on writing them up discovered they were horribly ugly.  Up until now you
have been spared.  That's what is different.

Sitting in the tub this afternoon I somehow started thinking about if
expressions one more time.  Here is the code I use as a workaround
(guaranteed unretouched photo!):

def choose(cond, a, b): # warning: evaluates all arguments

    if cond: return a
    else: return b

Naturally this isn't very good, or pep 308 wouldn't exist.  My "grand
insight" in the tub was simply that once could define another version of
this code:

def choose_eval(cond, a, b): # warning: evals all arguments

    if cond: return eval(a)
    else: return eval(b)

Heavy duty stuff by my present bathtub standards.  So to "delay" the
evaluation of an argument, just quote it.  Wow--just like lithp.  Example:

choose_eval(a < b,"foo(a)","spam(b)")

Yes, I know this is absolutely trivial stuff, but hey, it was news to me.

What if one of the arguments to choose_eval should evaluate to a string?
One has to do something like:

choose_eval (a < b,"'less'","meaningOf(42)")

So, I think doing nothing is almost good enough, provided:

1. We reveal the secret embodied in the definition of choose_eval() above
and (I considered patenting it while the bathwater drained out.)

2. We add a string method (say, quote) that quotes any string such that
eval(s.quote()) evaluates to s for any string s.

Then the second example above could be written as:

choose_eval(a < b,"less".quote(),"meaningOf(42)")

To be clear, I am _not_ suggesting anything be added to the global
namespace.  I am suggesting that Python's documentation need only discuss
the two kinds of "conditional" functions shown above.  It will then be up to
the user to choose two names that will work for the task at hand.  If
standard names need to be chosen, that could be dealt with in pep 666.

Edward

P.S. In spite of my lighthearted tone I believe that it is important to put
this issue to rest, one way or the other. That is why the "grand secret"
(tm) must be discussed in the official Python docs, and why a quote string
method would be a good idea.

P.P.S. All criticisms of this brilliant proposal are obviously impertinent,
even if valid.

EKR
--------------------------------------------------------------------
Edward K. Ream   email:  edream at tds.net
Leo: Literate Editor with Outlines
Leo: http://personalpages.tds.net/~edream/front.html
--------------------------------------------------------------------