PEP-308 a "simplicity-first" alternative

[Bengt Richter]

On Wed, 12 Feb 2003 19:03:43 -0800, Erik Max Francis <max at alcyone.com> wrote:

>Bengt Richter wrote:
>
>> "That cure" hasn't been presented before AFAIK, so how can you have
>> pointed
>> out anything about it before?
>
>Um, you've posted about it at least a half-dozen times, now probably
>approaching a dozen.
>
Sorry, I must have missed a previous post of yours pointing something
out about it. (I didn't miss comments on c -> x -> y >!< e -> ev
-- in fact I got an LOL (not at you) out of one ;-)

Sometimes things arrive in strange time order too, so there
may be something I haven't seen.

>> It is _not_ a ternary syntax. {x} is an expression all by itself, just
>> as [x] is,
>> except that all it does is guarantee that {x} will be seen as true in
>> any logical
>> expression context.
>
>I understand that.  It's a special form that says "evaluate me as True
>in one context, but evaluate me to something else in another context."
You already have that. I.e., think of what
    result = x and y
does. You aren't thinking the result is 1 or 0, right? (Unless it's 1 and 1
or 0 and whatever, respectively).
For that matter, consider x in the two contexts of x in
    (if not x: x else: y) # <=> x and y

>This is remarkably confusing, and as for correcting the and/or idiom,
>only complicates it.  Now it's even _more_ idiomatic, and even _harder_
>to read.
If you have a hard time with Python's short-circuit and/or expressions, yes,
but if you just read it the way the interpreter does, the concept of
a truth-wrapping-skin on a term shouldn't be very hard to read
(ISTM -- but maybe I have grown too familiar with  Python short-circuiting).
>
>And I seriously doubt that you've considered the full ramification of
>the meaning of the syntax itself.  How would it be implemented?  How
>would it be used in other situations?

I doubt if implementation would be a big deal. Consider that there would
be no way to bind a truth-wrapped value, since z={x} would bind to the value
of x, and likewise foo({x}) would pass the value. The affected contexts would
be if {x}:..., elif {x}:..., while {x}:... and of course operands
of "and" and "or" which all seem to involve JUMP_IF_FALSE, plus UNARY_NOT.
IWG it shouldn't be that hard to recognize a truth-wrapped node in the parse tree
and generate a plain jump instead, and a False for -{x}, but you never know until
you're there, so I admit to handwaving based on a hunch ;-) Any other context would
just generate code to use the "wrapped" value normally. Most of those are just
for consistency, since there's no reason to write something like x={y}, even though
it's legal.

As to use in other situations, some of them might not be a good thing to encourage,
but e.g. it makes it easy to insert an arbitrary function call in the context of
the evaluation of a logical expression, since "{whatever} and x" can be substituted
any place "x" by itself can go. Whatever could be a function call or a method call like
this contrived logger

    x and {log.append('in middle of x and y expression where x is True so far')} and y

>
>Not to mention the fact that it uses curly braces which suggest
>dictionaries when none are to be found anywhere nearby.

Worse, as I just saw that Timothy Delaney has brought up,
my truth-wrap clashes with proposed set notation ;-/

What else would make a simple wrapping syntax?
Oh well, I think I need a 308 moratorium ;-)

[Oops, this didn't get posted. Guess I'll send it.]

Regards,
Bengt Richter