Mailing List Archive

> Moshe Zadka wrote:
> Seriously, I disagree with the basic premise of you and Jim: you can
> *already* have control structures inside experessions with and/or, so
> even for Jim's twisted meanings for "add new functionality to the
> language" it's not true.

Have you ever tried to teach this to relatively experienced programmers
(never mind novices) whose background is Fortran, Modula-2, Ada, or
anything other than C/C++/Java? It's *really* hard to get the idea
across. I tried it in the first Python course I taught at LANL, and wound
up spending 15 minutes trying to unconfuse people (and failed). Afterward,
one guy said that it made even less sense than using integer offsets to
fake linked lists in Fortran-77...

Greg

On Mon, 31 Jan 2000 gvwilson@nevex.com wrote:

> > Moshe Zadka wrote:
> > Seriously, I disagree with the basic premise of you and Jim: you can
> > *already* have control structures inside experessions with and/or, so
> > even for Jim's twisted meanings for "add new functionality to the
> > language" it's not true.
>
<but it's hard to get the idea across>

You're most certainly right. This, however, refers to usability, not
functionality. It makes existing functionality usable by non-timbots. A
worthy goal, but it's not the same as adding new functionality.

--
Moshe Zadka <mzadka@geocities.com>.
INTERNET: Learn what you know.
Share what you don't.

Tim Peters <tim_one@email.msn.com>:
> > ...
> > The solution can be the same as what Algol used: 'if' outside
> > parentheses is a statement, and inside parentheses is an expression.
> > It's a bit of a grammar rearrangement, but totally unambiguous.
>
> If I didn't know better <wink>, I'd say there's an actual consensus here:
> it seems we would all agree to "(if cond then true else false)" spelling.
> Not to be overlooked is Christian's enhancement, allowing "elif" too (beats
> all heck out of guessing how ?: nests!).
>
> Eric, are you also in agreement?

I'm not sure. I'm concerned that this syntax will actually be more
viually confusing that ?:. That having been said, I am more interested
in having ternary-select be in the language than I am in arguing about its
exact syntax.
--
<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Men trained in arms from their infancy, and animated by the love of liberty,
will afford neither a cheap or easy conquest.
-- From the Declaration of the Continental Congress, July 1775.

[Tim]
>> If I didn't know better <wink>, I'd say there's an actual
>> consensus here: it seems we would all agree to "(if cond then
>> true else false)" spelling.

[Ka-Ping Yee]
> Actually, i'm afraid i don't. I initially chose the "then/else"
> spelling specifically because "if" flags the eye to the beginning
> of a statement. My line of thinking was, "'then' for expressions,
> 'if' for statements."

OK, I'm baffled. I probably don't recall your suggestion -- the implication
is that it didn't use the word "if"? If so, I probably read it and assumed
you left out the "if" my mistake <wink>. Seriously, "excessively novel"
isn't called for here: *tons* of languages have used if/then/else for this
purpose without difficulty.

...

>> ... couldn't the grammar use WORD and verify it's
>> specifically "then" later?

> Quite possibly, yes -- though i figured it wouldn't be *too*
> large an issue to make "then" a keyword, since i can't imagine
> anyone naming a symbol "then" except under the most freakish
> of circumstances. A quick check shows no symbol by that name
> in any of the Python scripts or modules we have here.

No keyword has been added to Python since "lambda", and you can be certain
Guido will never add another (at least not to Python1) -- this is an
absolute non-starter. Ping, *you* used to know this better than anyone
<wink>.

On Mon, 31 Jan 2000, Tim Peters wrote:
> If I didn't know better <wink>, I'd say there's an actual consensus here:
> it seems we would all agree to "(if cond then true else false)" spelling.

Actually, i'm afraid i don't. I initially chose the "then/else"
spelling specifically because "if" flags the eye to the beginning
of a statement. My line of thinking was, "'then' for expressions,
'if' for statements."

> I had already channeled that for the group's benefit <wink>. For 1.6,
> without absurd overloading of some other keyword (like "if cond def true
> ..."), that seems to leave
>
> (if cond: true else false)

Sorry, i like that even less. It seems to abuse the colon, for the
colon (to me) signals both (a) This Is A Statement and (b) This Begins
A Block, neither of which are true here.

> How much is that hated? I hate it myself, not least because I'd have to
> change IDLE's parser to guarantee it couldn't get confused by the colon
> here:
>
> big = (
> if x >= y:
> x else y)

I consider this a symptom of the colon-abuse i just described...

> BTW, I'm not entirely convinced "then" would have to be a keyword to make
> "if x then y else z" work: couldn't the grammar use WORD and verify it's
> specifically "then" later?

Quite possibly, yes -- though i figured it wouldn't be *too*
large an issue to make "then" a keyword, since i can't imagine
anyone naming a symbol "then" except under the most freakish
of circumstances. A quick check shows no symbol by that name
in any of the Python scripts or modules we have here.


-- ?!ng

Ka-Ping Yee <ping@lfw.org>:
> Might as well summarize the other suggestions so far:
>
> return if x > 0: x else -x
> return x > 0 ? x else -x

Mixing ? or : with a keyword is just *ugly*. Yes, I know I said I wasn't
that interested in arguing syntax, but these make my gorge rise.

> return x > 0 ? x : -x

I think the other suggestions are making this one look better. At this
point I have to like either this or the algol68 style Guido mentioned.
--
<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

The conclusion is thus inescapable that the history, concept, and
wording of the second amendment to the Constitution of the United
States, as well as its interpretation by every major commentator and
court in the first half-century after its ratification, indicates
that what is protected is an individual right of a private citizen
to own and carry firearms in a peaceful manner.
-- Report of the Subcommittee On The Constitution of the Committee On
The Judiciary, United States Senate, 97th Congress, second session
(February, 1982), SuDoc# Y4.J 89/2: Ar 5/5

On Mon, 31 Jan 2000, Tim Peters wrote:

> [Tim]
> >> If I didn't know better <wink>, I'd say there's an actual
> >> consensus here: it seems we would all agree to "(if cond then
> >> true else false)" spelling.
>
> [Ka-Ping Yee]
> > Actually, i'm afraid i don't. I initially chose the "then/else"
> > spelling specifically because "if" flags the eye to the beginning
> > of a statement. My line of thinking was, "'then' for expressions,
> > 'if' for statements."
>
> OK, I'm baffled. I probably don't recall your suggestion -- the implication
> is that it didn't use the word "if"? If so, I probably read it and assumed
> you left out the "if" my mistake <wink>.

Yeah, my suggestion was, e.g.

def abs(x):
return x > 0 then x else -x

Might as well summarize the other suggestions so far:

return x > 0 ? x else -x

return x > 0 ? x : -x

return if x > 0: x else -x

Have i missed any?

Oh, yes, and here is the control group.

return x > 0 and x or -x

return (x > 0 and [x] or [-x])[0]

if x > 0:
return x
else:
return -x


> Seriously, "excessively novel" isn't called for here:
> *tons* of languages have used if/then/else for this
> purpose without difficulty.

Yes, you're right about that.

> No keyword has been added to Python since "lambda", and you can be certain
> Guido will never add another (at least not to Python1) -- this is an
> absolute non-starter. Ping, *you* used to know this better than anyone
> <wink>.

Okay, okay. You probably have a better memory about this than i do. :)

Assuming that "then" will never be made a keyword, i would probably
go with "x > 0 ? x else -x". "if" seems to shout "statement" too
loudly at me, and colons seem too loaded.

Another issue with the last suggestion: how do you explain putting a
colon after the condition but not after the "else"?


-- ?!ng

On Mon, 31 Jan 2000, Ka-Ping Yee wrote:
> On Mon, 31 Jan 2000, Tim Peters wrote:
>...
> > No keyword has been added to Python since "lambda", and you can be certain
> > Guido will never add another (at least not to Python1) -- this is an
> > absolute non-starter. Ping, *you* used to know this better than anyone
> > <wink>.
>
> Okay, okay. You probably have a better memory about this than i do. :)

Actually, Tim's memory is failing. "assert" was added in 1.5. :-)

Not that this adds to the debate at all :-), but I figured that I am
obligated to knock a chair leg out from under Tim every now and then.

Cheers,
-g

p.s. I'm against a ternary operator. use an if/else statement. use
def instead of lambda (lambda is the only rational basis given so far to
add the operator, but it is bogus to start with)

--
Greg Stein, http://www.lyra.org/

[Tim]
>> No keyword has been added to Python since "lambda" ...

[Greg Stein]
> Actually, Tim's memory is failing. "assert" was added in 1.5. :-)
>
> Not that this adds to the debate at all :-), but I figured that I am
> obligated to knock a chair leg out from under Tim every now and then.

Actually, in 1.5 Guido *removed* lambda; then he added assert; then he had
second thoughts about lambda and added it again. That's why it's the last
one added.

You're right: the older I get the less effective my bullshit gets <wink>.
Done well, young one!

> p.s. I'm against a ternary operator. use an if/else statement. use
> def instead of lambda (lambda is the only rational basis given so far to
> add the operator, but it is bogus to start with)

Ah, there's nothing like the smell of consensus in the morning! Except
maybe napalm.

[Ping]
> Yeah, my suggestion was, e.g.
>
> def abs(x):
> return x > 0 then x else -x


Yup, I *did* mentally insert an "if" for you. You're welcome <wink>.

> Might as well summarize the other suggestions so far:
>
> return x > 0 ? x else -x

Toss it -- *nobody* wants it (if that's one I suggested, I get to retract
it).

> return x > 0 ? x : -x

Has anyone other than Eric come out explicitly in favor of this spelling (I
know others have come out in favor of a ternary operator, but don't recall
much love for this syntax)?

> return if x > 0: x else -x

I get to retract that too (heck, I said I hated that one in the same
sentence I tossed it out ...).

> Have i missed any?

Yes, the utterly conventional and perfectly clear one:

return (if x > 0 then x else -x)

If we don't buy into Guido's keyword argument, it's feasible.

There was also some Perlish atrocity (not that I'm judging ...) like

return x if x > 0 else -x

> Assuming that "then" will never be made a keyword, i would probably
> go with "x > 0 ? x else -x". "if" seems to shout "statement" too
> loudly at me, and colons seem too loaded.

Too late: it was mine & I retracted it <wink>. "if" doesn't really *shout*
stmt unless it's at the start of a line. Wrap it in parens too and it's
barely a whisper.

> Another issue with the last suggestion: how do you explain putting a
> colon after the condition but not after the "else"?

The truth: "Because Guido is afraid of new keywords" <wink>.

Maybe this would be a good time to write a dozen or so examples using
alternative syntaxes (syntaxii?), and stick 'em in front of a bunch of
people who haven't been part of this discussion, and ask 'em "what does
this do"?

(Footnote: check out David Scanlan's article in the Sept. 1989 issue of
"IEEE Software". Turns out that flowcharts are actually more readable
than pseudocode --- the research that claimed to show otherwise was
biased by (among other things) comparing structured pseudocode with
spaghetti flowcharts... One li'l bit of sloppy science, and the world
turns its back on something useful...)

Ellipsistically yours,
Greg

> Yeah, my suggestion was, e.g.
>
> def abs(x):
> return x > 0 then x else -x
>
> Might as well summarize the other suggestions so far:
>
> return x > 0 ? x else -x
>
> return x > 0 ? x : -x
>
> return if x > 0: x else -x
>
> Have i missed any?

return if x > 0 then x else -x

In some contexts, parentheses must be used, e.g.

(if c then a else b)[0] = 1

> > No keyword has been added to Python since "lambda", and you can be certain
> > Guido will never add another (at least not to Python1) -- this is an
> > absolute non-starter. Ping, *you* used to know this better than anyone
> > <wink>.
>
> Okay, okay. You probably have a better memory about this than i do. :)

Hm, I was just thinking that 'then' wouldn't be the hardest keyword to
add... But I should probably stick with Tim's suggestion.

> Assuming that "then" will never be made a keyword, i would probably
> go with "x > 0 ? x else -x". "if" seems to shout "statement" too
> loudly at me, and colons seem too loaded.

But "if" is in good company.

> Another issue with the last suggestion: how do you explain putting a
> colon after the condition but not after the "else"?

Whoever proposed that was terribly confused.

--Guido van Rossum (home page: http://www.python.org/~guido/)

Greg Stein writes:
> p.s. I'm against a ternary operator. use an if/else statement. use
> def instead of lambda (lambda is the only rational basis given so far to
> add the operator, but it is bogus to start with)

Actually, the places I'd use it most would be probably be in
constructing parameters to string formatting operations. Grepping
back in my memory, that's usually where I've wanted it.
I very rarely use lambda, and usually change it on the next
iteration on those cases when I do.


-Fred

--
Fred L. Drake, Jr. <fdrake at acm.org>
Corporation for National Research Initiatives

Fred L. Drake, Jr. writes:
> Greg Stein writes:
> > p.s. I'm against a ternary operator. use an if/else statement. use
> > def instead of lambda (lambda is the only rational basis given so far to
> > add the operator, but it is bogus to start with)
>
> Actually, the places I'd use it most would be probably be in
> constructing parameters to string formatting operations. Grepping
> back in my memory, that's usually where I've wanted it.

Boy does that ring a big bell. Was ambivalent, now I'm all for it
(either C syntax or "then" syntax, don't care).

> I very rarely use lambda, and usually change it on the next
> iteration on those cases when I do.

Use them mostly in GUIs where no smarts are required.

- Gordon

Gordon McMillan wrote:
>
> Fred L. Drake, Jr. writes:
> > Greg Stein writes:
> > > p.s. I'm against a ternary operator. use an if/else statement. use
> > > def instead of lambda (lambda is the only rational basis given so far to
> > > add the operator, but it is bogus to start with)
> >
> > Actually, the places I'd use it most would be probably be in
> > constructing parameters to string formatting operations. Grepping
> > back in my memory, that's usually where I've wanted it.
>
> Boy does that ring a big bell. Was ambivalent, now I'm all for it
> (either C syntax or "then" syntax, don't care).

So am I! Conditional expressions make very much sense for
constructing objects on-the-fly. It is quite common to
denote tuples, lists and dicts directly in Python code,
like so:

mapping_table = {
1: "one",
2: "two",
}

and so on. To parameterise them, we can either use different tables
embedded in an if, or use an expression inside the denotation:

language = 1

mapping_table = {
1: ("one", "eins")[language],
2: ("two", "zwei")[language],
}

but with expressions, we get to

mapping_table = {
1: language == 0 ? "one" : "eins",
2: language == 0 ? "two" : "zwei",
}

Well, maybe I had better chosen a different example, since the
language example looks better with indexing here.

How would we spell an elif? Would we at all?

# languages: 0 - English 1 - German 2 - Finnish

mapping_table = {
1: language == 0 ? "one" : language == 1 ? "eins", "yksi",
2: language == 0 ? "two" : language == 2 ? "zwei", "kaksi",
3: language == 0 ? "three" : language == 2 ? "drei", "kolme",
}

(yes the zero slot is missing - forgot what that is in Finnish:)

Would conditionals also be valid on the LHS of assignments?

target ? a : b = language ? "one" : "eins"

grmbl - chris

--
Christian Tismer :^) <mailto:tismer@appliedbiometrics.com>
Applied Biometrics GmbH : Have a break! Take a ride on Python's
Düppelstr. 31 : *Starship* http://starship.python.net
12163 Berlin : PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF
we're tired of banana software - shipped green, ripens at home

[Greg Wilson]
> (Footnote: check out David Scanlan's article in the Sept. 1989 issue of
> "IEEE Software". Turns out that flowcharts are actually more readable
> than pseudocode --- the research that claimed to show otherwise was
> biased by (among other things) comparing structured pseudocode with
> spaghetti flowcharts... One li'l bit of sloppy science, and the world
> turns its back on something useful...)

Oh, I don't know -- "visual programming" systems keep getting reinvented, so
I doubt they'll be lost to us forever: executable flowcharts are at least
as sensible as executable pseudocode (which latter Python partly aimed for).

I'm old enough that I actually suffered many textbooks that used flowcharts.
As I recall, they were absolutely worthless -- and in reviewing a few of
them just now, I see that this assessment was far too generous <wink>.
Lines crossing willy-nilly, dozens of single- and two(!)-letter "off page
connectors", ... yikes! If the study used spaghetti flowcharts, I expect
they used what was simply common practice at the time. I have seen a few
good flowcharts, though, and they were cool. How about a "folding"
graphical editor, so we could find & expand the logic levels of particular
interest without losing the big picture ...

oops-just-realized-this-has-nothing-to-do-with-1.6<wink>-ly y'rs - tim

[.Tim, makes a huge production over Guido's supposed intractability
on the issue of new keywords]

[Guido]
> Hm, I was just thinking that 'then' wouldn't be the hardest keyword to
> add...

Man, you *are* Unfathomable <0.9 wink>! Even if true, you should never have
admitted to it <0.1 wink>.

> But I should probably stick with Tim's suggestion.

Tim would.

[Ping]
>> Another issue with the last suggestion: how do you explain putting a
>> colon after the condition but not after the "else"?

> Whoever proposed that was terribly confused.

That was me. It was just brainstorming, so you wouldn't have to <wink>.

i-disowned-it-in-the-same-paragraph-i-introduced-it-but-
all-ideas-take-on-a-hideous-life-of-their-own-ly y'rs - tim

On Tue, 1 Feb 2000, Guido van Rossum wrote:
>
> Hm, I was just thinking that 'then' wouldn't be the hardest keyword to
> add... But I should probably stick with Tim's suggestion.

Wow, maybe i shouldn't have given in so fast. Oh, well. :)


-- ?!ng

Guido van Rossum wrote:
>
> Dear developers,
>
> Eric Raymond has sent me the following patch, which adds conditional
> expressions to Python. I'd like to hear opinions on whether this is a
> good thing to add to Python, and whether this is the right syntax.
>

Although Eric's patch is cute, I think this language shortcut is
unnecessary for Python. I'd support a do/while shortcut though ;-)
It's more popular and would fit "naturally" into the language for
most programmers.

Overall, it seems to me that the next major version of Python needs
to be cleaned, instead of being enriched. Both the language and the
internals. We have enough experience already for moving in this
direction. (I'm not speaking about new packages/libs or additional
core facilities, like Unicode, that need to integrated).

--
Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252

> [Tim]
> Man, you *are* Unfathomable <0.9 wink>! Even if true, you should
> never have admitted to it <0.1 wink>.

I think that's supposed to be <wink fraction="0.9"/>, isn't it?

Greg

Greg Wilson wrote:
> > [Tim]
> > Man, you *are* Unfathomable <0.9 wink>! Even if true, you should
> > never have admitted to it <0.1 wink>.
>
> I think that's supposed to be <wink fraction="0.9"/>, isn't it?

not in this case. quoting a leading bot implementor:

"We did requirements and task analysis, iterative
design, and user testing. You'd almost think emails
were an interface between people and bots."

and I can assure you that proving that human beings don't
like weird but formally well designed syntaxes was the easy
part of that project... (but don't tell the schemers ;-)

</F>

"Larry Wall should be shot. Along with Bill Joy and Eric Allman."
-- Daniel Finster, on comp.lang.lisp

"Why, just because you guys frittered away a 20-year headstart?"
-- Larry Wall

[Tim]
> Man, you *are* Unfathomable <0.9 wink>! Even if true, you should
> never have admitted to it <0.1 wink>.

[Greg Wilson]
> I think that's supposed to be <wink fraction="0.9"/>, isn't it?

[Fredrik Lundh]
> not in this case. quoting a leading bot implementor:
>
> "We did requirements and task analysis, iterative
> design, and user testing. You'd almost think emails
> were an interface between people and bots."
>
> and I can assure you that proving that human beings don't
> like weird but formally well designed syntaxes was the easy
> part of that project... (but don't tell the schemers ;-)

Right on, effbot! "Bots Helping Bots" is our motto. I'm quite sure the
timbot's use of <wink> predates the Web's twisted formalization of what
originally started life as a typographic device in a snail-mail newsletter,
when the timbot discovered that "real people" had no idea what to make of
;-) style emoticons. User testing is exactly on target. Iterative design,
too: the timbot's original use of [grin] didn't work nearly as well. The
introduction of fractional winkery was actually a minor refinement, yet
widely promoted by intuitionists as if it were the key idea. Feh.

> </F>
>
> "Larry Wall should be shot. Along with Bill Joy and Eric Allman."
> -- Daniel Finster, on comp.lang.lisp
>
> "Why, just because you guys frittered away a 20-year headstart?"
> -- Larry Wall

Say what you will about Perl, but you gotta love Larry! I recently filed a
Perl bug that was apparently introduced the day Perl5 hit the streets and
somehow went unnoticed for years, and had a nice exchange with him. Looking
over other recent bugs, I stumbled into this one first:

@array = "0" .. -1;

That, of course, computes an array of 100 elements, "0" thru "99": the
string "0" gets magically autoincremented, as if it were an integer, until
the *length* of the resulting string exceeds the length of the string "-1".
That this wasn't justified as "a feature" gives me hope that Guido's
presence on earth has done *some* little bit of good <wink>.

time-for-an-oil-change-ly y'rs - tim