PEP 308: Discussion Summary

Bengt Richter bokr at oz.net
Sun Feb 23 01:54:24 EST 2003


On Sun, 23 Feb 2003 11:03:35 +1300, Paul Foley <see at below.invalid> wrote:

>On 22 Feb 2003 15:58:38 GMT, Bengt Richter wrote:
>
>> On Thu, 20 Feb 2003 07:48:52 -0800, David Eppstein <eppstein at ics.uci.edu> wrote:
>>> In article <m2znorz2td.fsf at mycroft.actrix.gen.nz>,
>>> Paul Foley <see at below.invalid> wrote:
>>> 
>>>> I made a similar suggestion: [cond1 -> expr1; cond2 -> expr2; ...] a
>>>> week or so ago.
>>    IMO '->' is easy to read and understand, but I would change semicolon to
>> something else, like a 2-dot ellipsis, e.g.,
>
>>     [cond1 -> expr1 .. cond2 -> expr2 .. cond3 -> expr3]
>
>Why?
So [] can be removed, partly. Partly because I thought I'd try something different
after scaring folks ;-) (with '><' in place of the ';'), and '..' looked less cluttered.

>
>> Of course, the square brackets would be syntactic sugar in many cases,
>> so perhaps they could be optional parens instead.
>
>>     (cond1 -> expr1 -> default)
>
>Yeah, you suggested that before, but I think it's rather ugly...and
Yeah, I did suggest it, but not derived from the general format with ".." ;-)

>the meaning is unclear -- it looks to me like it should evaluate
>cond1, and if that's true it should evaluate expr1, and if that's true
>it should evaluate default!  I.e., [cond1 and expr1 -> default].
You'd have to parenthesize to get that, i.e.,
       (cond1 -> (expr1 -> default))

but you may be right. I think we should all sleep on it for a couple weeks
(as I am about to do ;-)

>
>Parens can't be optional in my version, because the first semicolon
>would end the expression and start a new statement (which is why
>semicolons are a good choice -- they already have similar meaning.
It's conceivable you could change my opinion on semicolon, but I need
to dissociate it from always-means-a-statement-is-next ;-)

>".." doesn't mean anything, and "expr1 .. cond2" looks like some kind
>of range expression.  That's also why I prefer square brackets -- if
C'mon, if it doesn't mean anything, no fair claiming it makes something
look like something ;-) I intended it to mean, "another clause coming"
(in a sequence of such).

>it used parentheses, they /should/ be optional.  Even if it wasn't for
>the semicolons, bracketing the expression should be a requirement)
Kind of ugly if the expression is used as a list index or dict key, though.

I'm wondering if the presenation for vote will adequately show such downsides
as well as the best-looking uses.
>
>>>> I think using commas to separate the clauses is a bad idea; semicolons
>>>> work much better, and "->" is more a obvious choice than ":".  There's
>>>> no need for a "default" value (I'd raise an exception if none of the
>>>> conditions are met)
>>> 
>>> Semicolons are overloaded.  If you're going to do something like this, 
>
>Semicolons are overloaded???  Do they have any meaning now except as a
>separator for several statements on the same line?
No, that's it exactly. They suggest "statement" really strongly, which is
an obstacle to introducing it in expression context.
>
>>> || (double vertical bar) might be better for expressing the disjunctive
>
>Yuck.
>
I don't know. It wasn't last on my list. Double characters are easy to type ;-)

If we had an unobtrusive alternative to white space ('..' ? ;-) we could transliterate lisp
stuff practically literally.

    (cond .. (c1 .. x11 .. x12 .. x12) .. (c2 .. x2) .. (c3 .. x31 ..x32) .. (True .. xdefault))

    (if .. c1 .. xthen .. xelse)

;-)

Regards,
Bengt Richter




More information about the Python-list mailing list