ternary operator
David Gausebeck
and one of the annoyances that I ran into right away was the lack of a
ternary ?: operator.
After looking around a little, I found a number of discussions by
others who have had the same problem. There are a few workarounds for
it, but none are very good.
The C expression "a ? b : c" can be emulated in python with
"a and b or c"
if b is not false. If b could be false, then you can use
"(a and [b] or [c])[0]".
In addition to the second (safer) form being fairly ugly, both
versions make for code that's awkward to read, as they're using 'and'
and 'or' to return values rather than evaluate truth.
The other alternative is to declare a function f(a, b, c) which
returns the desired value. The problems with this are that it isn't
standard (so code using it wouldn't be quite as easy to read), and
that it would have to be declared over and over.
So, a couple questions:
1) Is the lack of a ternary operator widely considered a (minor)
shortcoming of python, or is it just a few holdouts from C/C++ who
care?
2) Is there any better workaround than the ones I've listed above?
Finally, a thought on the solution I'd like to see... I agree that
the C syntax of a ? b : c wouldn't really work nicely in python, but
perhaps a unary ? operator acting on a list/tuple would. Instead of
"a ? b : c", python could support
"?(a, b, c)".
The main disadvantage I can see to the syntax at this point is that it
wouldn't support short-circuiting.
-Dave
John Roth
"David Gausebeck" <gauseb...@paypal.com> wrote in message
news:3e404255....@news.cis.dfn.de...
> I've recently started using python from a primarily C/C++ background,
> and one of the annoyances that I ran into right away was the lack of a
> ternary ?: operator.
>
> After looking around a little, I found a number of discussions by
> others who have had the same problem. There are a few workarounds for
> it, but none are very good.
>
> The C expression "a ? b : c" can be emulated in python with
> "a and b or c"
> if b is not false. If b could be false, then you can use
> "(a and [b] or [c])[0]".
That's the accepted workaround. I don't think anyone likes it.
> In addition to the second (safer) form being fairly ugly, both
> versions make for code that's awkward to read, as they're using 'and'
> and 'or' to return values rather than evaluate truth.
Well, that's not really that much of a problem, since you see the
same thing in other contexts. The odd behavior of 'and' and 'or'
is one of those things that makes Python something more than
"just another language."
It's used, for example, to provide defaulting.
> The other alternative is to declare a function f(a, b, c) which
> returns the desired value. The problems with this are that it isn't
> standard (so code using it wouldn't be quite as easy to read), and
> that it would have to be declared over and over.
As you point out, this doesn't short circuit, unless you define 'b' and
'c' using lambdas. That's megaugly.
> So, a couple questions:
>
> 1) Is the lack of a ternary operator widely considered a (minor)
> shortcoming of python, or is it just a few holdouts from C/C++ who
> care?
It certainly isn't enough of a shortcoming to drive people away in
droves.
> 2) Is there any better workaround than the ones I've listed above?
Not that I've heard of.
> Finally, a thought on the solution I'd like to see... I agree that
> the C syntax of a ? b : c wouldn't really work nicely in python, but
> perhaps a unary ? operator acting on a list/tuple would. Instead of
> "a ? b : c", python could support
> "?(a, b, c)".
>
> The main disadvantage I can see to the syntax at this point is that it
> wouldn't support short-circuiting. You also run into the ambiguity
between tuples and function parameter lists. If '?' is an operator,
that's
a tuple, but if it's a wierd function name, that's a parameter list.
You might have more luck pursuing lazy evaluation in functions.
If you have that, a functional version of if, in a similar style to TCL,
would be incredibly easy to write. This would, of course, also support
elif.
John Roth
>
> -Dave
Chad Netzer
> I've recently started using python from a primarily C/C++ background,
> and one of the annoyances that I ran into right away was the lack of a
> ternary ?: operator.
Some people have advocated:
(b,c)[not a]
which is comparable (except for the shortcutting evaluation) to:
a ? b : c
Best to use it sparingly, or only when you require a lot of it at once
(and can write a brief local comment to explain it), IMO.
--
Bay Area Python Interest Group - http://www.baypiggies.net/
Chad Netzer
(any opinion expressed is my own and not NASA's or my employer's)
Alexander Schmolck
> I've recently started using python from a primarily C/C++ background,
> and one of the annoyances that I ran into right away was the lack of a
> ternary ?: operator.
That python tries to seperate statements (assignment, conditionals etc.) and
expressions has it pros and cons. The pros are:
- it makes code more uniform (there is only one way to write an "if test"
etc.)
- it makes cramming too many things into a single line painful. I have often
found that python getting into my way of being too "clever" has helped me to
write cleaner and better code.
I think you should maybe first "do as the Romans do" for a couple of kloc and
see how you like it then, before attempting to work around the "missing"
ternary (BTW: I don't think there is a language designed by people who knew
what they were doing that has a ternary operator; all the non-braindead
languages I've seen that allow conditionals in expressions don't distinguish
between expressions and statements to begin with).
> The C expression "a ? b : c" can be emulated in python with
> "a and b or c"
> if b is not false. If b could be false, then you can use
> "(a and [b] or [c])[0]".
> 2) Is there any better workaround than the ones I've listed above?
Since you don't seem to want shortcircuting,``(b,c)[not a]`` maybe?
> Finally, a thought on the solution I'd like to see... I agree that
> the C syntax of a ? b : c wouldn't really work nicely in python, but
> perhaps a unary ? operator acting on a list/tuple would. Instead of
> "a ? b : c", python could support
> "?(a, b, c)".
<blech>
>
> The main disadvantage I can see to the syntax at this point is that it
> wouldn't support short-circuiting.
Indeed the "disadvantage" of having a `if-else`-statement simply evaluate
everything seems to outweight the disturbingly ugly and cryptic syntax and the
waste of one of the few still unused non-alphanumeric characters for no
expressive gain.
alex
Laura Creighton
operator only very rarely produces code that is easier to understand
and read. Very, very, very, rarely.
The rest of the time it just adds to the perceptual/conceptual load of
the person who is reading it.
In Python, the decision was made that it was better to let the people
read easily, rather than give them hard tough conceptual loads, which
only the well studied will understand. this newsgroup is not
reflective of it, because it is where those who like archana hang out
and write things that are hard to understand for the joy of doing
something difficult. Workday python is easier to read.
And the ternary operator flunks the 'worth the conceptual overload'
test. Therefore do not expect to see it soon.
---------
Note: I do not speak for a single member of python-dev. watch them
put a ternary in 2.4 all oblivious of my annoyance. This is just what
i have gleaned from discussions here, and the fact that there is no
ternary operator yet, despite years of some people wanting it.
Laura
Christopher A. Craig
> 2) Is there any better workaround than the ones I've listed above?
if a: x = b
else: x = c
do_something(x)
Quite clear, I would think. <.8 wink>
Python is generally thought to have caught on as a language because of
its simplicity. The developers really do try to make sure there is
always one, and only one obvious way to do things. Listcomps and
generators have detracted from this some, but I think the
expresiveness of them outweighs the syntactic complexity they add. I
do not feel the same about the ternary function.
--
Christopher A. Craig <list-...@ccraig.org>
"In the beginning the Universe was created. This has made a lot of people
very angry and been widely regarded as a bad move." Douglas Adams
Dan Bishop
> I've recently started using python from a primarily C/C++ background,
> and one of the annoyances that I ran into right away was the lack of a
> ternary ?: operator.
>
> After looking around a little, I found a number of discussions by
> others who have had the same problem. There are a few workarounds for
> it, but none are very good.
>
> shortcoming of python, or is it just a few holdouts from C/C++ who
> care?
> 2) Is there any better workaround than the ones I've listed above?
>
> Finally, a thought on the solution I'd like to see... I agree that
> the C syntax of a ? b : c wouldn't really work nicely in python, but
> perhaps a unary ? operator acting on a list/tuple would. Instead of
> "a ? b : c", python could support
> "?(a, b, c)".
>
> The main disadvantage I can see to the syntax at this point is that it
> wouldn't support short-circuiting.
I don't see the need to add a special operator for
non-short-circuiting conditionals. It would be to sufficent to make a
function like this standard:
def cond(selector, valTrue, valFalse):
if selector:
return valTrue
return valFalse
Dan Bishop
...
> Indeed the "disadvantage" of having a `if-else`-statement simply evaluate
> everything seems to outweight the disturbingly ugly and cryptic syntax and the
> waste of one of the few still unused non-alphanumeric characters for no
> expressive gain.
How about something like "(if a: b else c)", which uses no punctuation
or keywords other than those that are already part of the language?
Grant Edwards
> I don't see the need to add a special operator for
> non-short-circuiting conditionals. It would be to sufficent to
> make a function like this standard:
>
> def cond(selector, valTrue, valFalse):
> if selector:
> return valTrue
> return valFalse
Righ, that's easy enough, but how many bugs will be cause by
people forgetting that it doesn't short-circuit?
--
Grant Edwards grante Yow! Sometime in 1993
at NANCY SINATRA will lead a
visi.com BLOODLESS COUP on GUAM!!
John Roth
"Grant Edwards" <gra...@visi.com> wrote in message
news:3e418d36$0$147$a186...@newsreader.visi.com...
> In article <ad052e5c.03020...@posting.google.com>, Dan
Bishop wrote:
>
> > I don't see the need to add a special operator for
> > non-short-circuiting conditionals. It would be to sufficent to
> > make a function like this standard:
> >
> > def cond(selector, valTrue, valFalse):
> > if selector:
> > return valTrue
> > return valFalse
>
> Righ, that's easy enough, but how many bugs will be cause by
> people forgetting that it doesn't short-circuit?
Which is exactly the reason I suggested that it might be a good idea to
pursue some way of allowing a function to do lazy evaluation of its
operands.
A condition function would, as several people have said, be very
easy with that facility, and is the first use case. Hopefully, it's not
the
only use case, or it probably won't fly.
John Roth
Paul Rubin
> > > def cond(selector, valTrue, valFalse):
> > > if selector:
> > > return valTrue
> > > return valFalse
> >
> > Righ, that's easy enough, but how many bugs will be cause by
> > people forgetting that it doesn't short-circuit?
>
> Which is exactly the reason I suggested that it might be a good idea to
> pursue some way of allowing a function to do lazy evaluation of its
> operands.
value = (lambda: valTrue, lambda: valFalse)[not selector]()
Chad Netzer
> On 05 Feb 2003 09:49:33 -0500, Christopher A Craig wrote:
> > if a: x = b
> > else: x = c
>
> Urk. There really ought to be a PSU death squad dedicated to hunting
> down people who write code like that!
Well, earlier I posted the "x = (b,c)[not a]" non-idiom.
Do I need to get some bullet-proof underwear?
Christopher A. Craig
> On 05 Feb 2003 09:49:33 -0500, Christopher A Craig wrote:
>
> > gauseb...@paypal.com (David Gausebeck) writes:
> >> 2) Is there any better workaround than the ones I've listed above?
>
> > if a: x = b
> > else: x = c
>
> Urk. There really ought to be a PSU death squad dedicated to hunting
> down people who write code like that!
You like (b, c)[not a] better? I generally don't write code like
that, but it is more compact than the prefered way and anything is
better than the perl-line-noise-eqsue ternery work alikes that are
available.
--
Christopher A. Craig <list-...@ccraig.org>
Why be ISO9000 Compliant when you can be ISO9660 Compliant?
John Roth
"Paul Rubin" <phr-n...@NOSPAMnightsong.com> wrote in message
news:7xlm0ud...@ruckus.brouhaha.com...
Of course you can do it that way. Now try explaining that syntax
to your average COBOL programmer attempting to learn a more
modern language.
John Roth
Paul Rubin
> > value = (lambda: valTrue, lambda: valFalse)[not selector]()
>
> Of course you can do it that way. Now try explaining that syntax
> to your average COBOL programmer attempting to learn a more
> modern language.
Yeah. I've never understood this obsession with keeping conditional
expressions out of Python. They didn't confuse people in Algol-60 and
I think Pascal (designed as newbie language from the beginning) had
them too.
Of course Python doesn't NEED conditional expressions. It also
doesn't need to recognize the digits 8 or 9, since you can enter every
numeric constant in octal without using those digits. But if the most
frequently asked question in c.l.py is how do you enter a number in
decimal instead of octal, and the answer is always "you can't, but you
don't really need to" followed by long threads exchanging favorite
contorted workarounds for the problem, then maybe, just maybe, the
people who keep asking how to do it really have identified a
legitimate missing capability in the language. Sigh.
Erik Max Francis
> You like (b, c)[not a] better? I generally don't write code like
> that, but it is more compact than the prefered way and anything is
> better than the perl-line-noise-eqsue ternery work alikes that are
> available.
The main drive for a conditional operator is one which serves as an
expression, so the traditional solution involving an if...else statement
is sort of missing the point.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ War is like love, it always finds a way.
\__/ Bertolt Brecht
Bosskey.net: Return to Wolfenstein / http://www.bosskey.net/rtcw/
A personal guide to Return to Castle Wolfenstein.
Alex Martelli
...
> Yeah. I've never understood this obsession with keeping conditional
> expressions out of Python. They didn't confuse people in Algol-60 and
> I think Pascal (designed as newbie language from the beginning) had
> them too.
I believe you misremember. Pascal, as designed (as a language for
newbies) by N. Wirth, had no conditional expressions (and no logical
operators that ensured short-circuiting, either). Pascal was a very
deliberate reversion to simplicity from the complications of Algol-68
(I _think_ Algol 60 didn't have "short-circuiting conditional expressions"
either, and it did make a distinction between statements and expressions,
like Pascal and unlike Algol 68 -- but it's been far too long since I
actually used Algol for me to feel certain about it), so that is hardly
surprising.
I don't think there are implications about Python from the choices
historically made by Backus, Naur, Wirth, and others in the '60s, but
nevertheless I'd appreciate clarification by careful historians...
Alex
Erik Max Francis
> But if the most
> frequently asked question in c.l.py is how do you enter a number in
> decimal instead of octal, and the answer is always "you can't, but you
> don't really need to" followed by long threads exchanging favorite
> contorted workarounds for the problem, then maybe, just maybe, the
> people who keep asking how to do it really have identified a
> legitimate missing capability in the language. Sigh.
Well said. I still hold out on the possibility of Those In Power
changing their minds and including a conditional operator in a future
version. When I first started using Python, the three things I
genuinely missed were augmented assignments (although admittedly not
much), a separate Boolean type, and a conditional operator.
Augmented assignments were added to 2.0, and Booleans are now being
added to 2.3 (in a sudden change of heart and a declaration), both with
minimal impact; of the two, Booleans are far more "invasive" and even
then they'd only serve to be problematic in pathological code.
Conditional expressions, whatever syntax is chosen, also promise to have
utterly minimal impact (since whatever form it takes, it will have been
illegal before its introduction so it's automatically backward
compatible).
In some sense Booleans were a much harder sell than conditional
expressions, and now Booleans are in. Augmented assignments, surely,
had more ramifications on the parser and support methods than
conditional expressions would.
Maybe (at least, I still hope) a similar fate awaits conditional
expressions in the future.
Alex Martelli
...
>> value = (lambda: valTrue, lambda: valFalse)[not selector]()
>
> Of course you can do it that way. Now try explaining that syntax
> to your average COBOL programmer attempting to learn a more
> modern language.
Why would a Cobol programmer be looking for a "ternary" he's
never seen in Cobol?! Ternary is for C'ers, Perl'ers, etc. Cobolers
will be quite happy with:
if selector: value = valFalse
else: value = valTrue
Trust me -- I know several excellent Cobol experts and ternary
is NOT what they're looking for. "PICTURE" and other uses of
fixed-point are much more likely to be it, or maybe (though that
still baffles me a bit) "ADD a TO b GIVING c" as an alternative
to "weird, algebraic" (sic) "c = a + b" ...
Alex
Carlos Ribeiro
> Paul Rubin wrote:
> > Yeah. I've never understood this obsession with keeping conditional
> > expressions out of Python. They didn't confuse people in Algol-60 and
> > I think Pascal (designed as newbie language from the beginning) had
> > them too.
>
> I believe you misremember. Pascal, as designed (as a language for
> newbies) by N. Wirth, had no conditional expressions (and no logical
> operators that ensured short-circuiting, either).
I can tell for sure that Pascal did not support conditional expressions. Even
short circuiting is not part of the language - there is nothing in the
language definition about this. However, Borland line of Pascal compilers had
a switch to set the logical expression evaluation mode: short circuit or full
evaluation. That may be the reason why some people believe that (standard)
Pascal supported it.
> I don't think there are implications about Python from the choices
> historically made by Backus, Naur, Wirth, and others in the '60s, but
> nevertheless I'd appreciate clarification by careful historians...
It seems to be impossible not to be aware of the choices made by those people
- they've helped to define programming language design as a science. Now, if
would-be 'designers' just keeping throwing away feature after feature at
every new language design, it's their fault alone. Learning from the mistakes
(and successes) of the masters is the *best* education possible.
[btw, the adoption of indented blocks over brace/keyword delimited ones was a
deliberate design decision by Guido; I've read somewhere in a interview by
Guido himself that it involved a lot of considerations about the shortcomings
of the then-standard practice. So...]
Carlos Ribeiro
crib...@mail.inet.com.br
Delaney, Timothy C (Timothy)
>
> Paul Foley <s...@below.invalid> writes:
>
> > On 05 Feb 2003 09:49:33 -0500, Christopher A Craig wrote:
> >
> > > gauseb...@paypal.com (David Gausebeck) writes:
> > >> 2) Is there any better workaround than the ones I've
> listed above?
> >
> > > if a: x = b
> > > else: x = c
> >
> > Urk. There really ought to be a PSU death squad dedicated
> to hunting
> > down people who write code like that!
>
Nope. I like
if a:
x = b
else:
x = c
In fact, I have written into the Python style guide for my team explicitly to not write things like
if a: x = b
else: x = c
for much the same reason that I specify to not write
if (a)
x = b;
else
x = c;
or
if (a) x = b;
else x = c;
in C.
which is quite simply that they (a) don't convey the execution flow (indentation gives a visual representation), (b) are less extensible (they require remembering to move things around when you need more than one action) and (c) are very dangerous in the second case above.
Tim Delaney
Tim Peters
> ...
> (I _think_ Algol 60 didn't have "short-circuiting conditional
> expressions" either, and it did make a distinction between statements
> and expressions, like Pascal and unlike Algol 68 -- but it's been far
> too long since I actually used Algol for me to feel certain about it),
> so that is hardly surprising.
The Algol 60 Revised Report is available online; e.g., a nice rendering with
a few helpful hyperlinks is at
http://www.masswerk.at/algol60/report.htm
Your memories are all on target. Unlike as in Python, a bare expression
isn't allowed where a statement is required (Python blurred the distinction
for the benefit of interactive mode), so there's no confusion between Algol
60's if/then/else conditional statement and Algol 60's if/then/else
arithmetic expression (an "if" is the start of an Algol 60 statement if and
only if "if" is the first token of a statement following the statement's
labels (if any)).
> I don't think there are implications about Python from the choices
> historically made by Backus, Naur, Wirth, and others in the '60s, but
> nevertheless I'd appreciate clarification by careful historians...
Better to go to the source: the Algol 60 report is still a marvel of
succinct clarity.
nobody-has-time-for-brevity-anymore-ly y'rs - tim
Mike Meyer
> I believe you misremember. Pascal, as designed (as a language for
> newbies) by N. Wirth, had no conditional expressions (and no logical
> operators that ensured short-circuiting, either). Pascal was a very
> deliberate reversion to simplicity from the complications of Algol-68
> (I _think_ Algol 60 didn't have "short-circuiting conditional expressions"
> either, and it did make a distinction between statements and expressions,
> like Pascal and unlike Algol 68 -- but it's been far too long since I
> actually used Algol for me to feel certain about it), so that is hardly
> surprising.
You're right about Algol. No short circuiting conditionals. I don't
remember if the "block expression" was an Algol-W ism or from Algol
60.
Hey, that's what we need to make the people who want an assignment
operator happy! Block expressions.
Proposed syntax:
block:
<statements>
expression
and the value of the block is the value of the last expression in the
block. So you can write:
if block:
value = calculations()
value == 3:
calcuation_with_value(value)
and so on.
And yes, I really did write Algol that did things like
while begin statements; exrepssion end do begin statements end
I-hope-no-one-takes-this-seriously-ly, <mike
--
Mike Meyer <m...@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Paul Rubin
> The Algol 60 Revised Report is available online; e.g., a nice rendering with
> a few helpful hyperlinks is at
>
> http://www.masswerk.at/algol60/report.htm
Very cool!
> Your memories are all on target. Unlike as in Python, a bare expression
> isn't allowed where a statement is required (Python blurred the distinction
> for the benefit of interactive mode), so there's no confusion between Algol
> 60's if/then/else conditional statement and Algol 60's if/then/else
> arithmetic expression (an "if" is the start of an Algol 60 statement if and
> only if "if" is the first token of a statement following the statement's
> labels (if any)).
I'm not sure what you're getting at here. Algol 60 (from the revised
report) definitely supported short-circuiting conditional expressions.
From section 3.3.3:
In the more general arithmetic expression, which include if clauses,
one out of several simple arithmetic expressions is selected on the
basis of the actual values of the Boolean expression (cf. section
3.4. Boolean expressions). This selection is made as follows: The
Boolean expressions of the if clauses are evaluated one by one in the
sequence from left to right until one having the value true is
found. The value of the arithmetic expression is then the value of the
first arithmetic expression following this Boolean (the largest
arithmetic expression found in this position is understood). The
construction:
else <simple arithmetic expression>
is equivalent to the construction:
else if true then <simple arithmetic expression>
> Better to go to the source: the Algol 60 report is still a marvel of
> succinct clarity.
It's been said that Algol 60 is one of the few languages so well
designed that it improved not only on its predecessors, but on most of
its successors as well.
Mike Meyer
> "Grant Edwards" <gra...@visi.com> wrote in message
> news:3e418d36$0$147$a186...@newsreader.visi.com...
> > In article <ad052e5c.03020...@posting.google.com>, Dan
> Bishop wrote:
> >
> > > I don't see the need to add a special operator for
> > > non-short-circuiting conditionals. It would be to sufficent to
> > > make a function like this standard:
> > >
> > > def cond(selector, valTrue, valFalse):
> > > if selector:
> > > return valTrue
> > > return valFalse
> >
> > Righ, that's easy enough, but how many bugs will be cause by
> > people forgetting that it doesn't short-circuit?
>
> Which is exactly the reason I suggested that it might be a good idea to
> pursue some way of allowing a function to do lazy evaluation of its
> operands.
That way lies macros. You don't want to go there.
Actually, there are two ways to do that now. You've seen the lambda
version. Here's the string version.
def cond(test, val1, val2, locals = {}, globals = {}):
if test: return eval(val1, locals, globals)
else: return eval(val2, locals, globals)
so you can write something like this:
cond(a, "b", "c", locals())
Paul Rubin
> You're right about Algol. No short circuiting conditionals. I don't
> remember if the "block expression" was an Algol-W ism or from Algol 60.
What exactly do you mean by "short circuiting conditionals"?
I thought it just meant something like C's ternary operator.
Algol 60 had something like that. You could say
x = if a>=0 then sqrt(a) else sqrt(-a);
which would take the square root of the absolute value of a.
Short circuiting just means the non-selected branch doesn't get evaluated.
Paul Rubin
> > Which is exactly the reason I suggested that it might be a good idea to
> > pursue some way of allowing a function to do lazy evaluation of its
> > operands.
>
> That way lies macros. You don't want to go there.
I think Algol 60 had that ability too, without needing macros, because
of how call-by-name parameter passing worked.
Chad Netzer
> Hey, that's what we need to make the people who want an assignment
> operator happy! Block expressions.
>
> Proposed syntax:
>
> block:
> <statements>
> expression
>
> and the value of the block is the value of the last expression in the
> block.
Welcome to Ruby.
Tim Peters
>> rendering with a few helpful hyperlinks is at
>>
>> http://www.masswerk.at/algol60/report.htm
[Paul Rubin]
> Very cool!
Yup.
>> Your memories are all on target. Unlike as in Python, a bare
>> expression isn't allowed where a statement is required (Python
>> blurred the distinction for the benefit of interactive mode), so
>> there's no confusion between Algol 60's if/then/else conditional
>> statement and Algol 60's if/then/else arithmetic expression (an
>> "if" is the start of an Algol 60 statement if and only if "if" is
>> the first token of a statement following the statement's labels
>> (if any)).
> I'm not sure what you're getting at here.
The distinction between expressions and statements, much stronger in Algol
60 than in Python (every Python expression is a Python statement; no Algol
60 expression is an Algol 60 statement; a consequence is that if Python were
to add conditional expressions of the if/then/else form, seeing an initial
"if" would not be enough to distinguish the expression form from the
statement form, and that has consequences; Algol 60 didn't have this
problem).
> Algol 60 (from the revised report) definitely supported short-circuiting
> conditional expressions.
I didn't mention short-circuiting, although Alex did. I took his mention of
short-circuiting to mean that Algol 60's spelling of the boolean "and" and
"or" operators didn't short-circuit, which they didn't. Of course the "if
e1 then e2 else e3" flavor of conditional expression evaluated exactly one
of {e2, e3}. IOW, I did Alex the minor favor of assuming he wasn't an idiot
<wink>.
...
>> Better to go to the source: the Algol 60 report is still a marvel of
>> succinct clarity.
> It's been said that Algol 60 is one of the few languages so well
> designed that it improved not only on its predecessors, but on most of
> its successors as well.
Worth repeating.
David Gausebeck
>
>Nope. I like
>
> if a:
> else:
> x =3D c
>
>In fact, I have written into the Python style guide for my team =
>explicitly to not write things like
>
> else: x =3D c
>
>for much the same reason that I specify to not write
>
> if (a)
> else
> x =3D c;
>
>or
>
> if (a) x =3D b;
> else x =3D c;
>
>in C.
I agree that the style you're promoting makes the logic clearer.
However, my main goal is the clarity of the code as a whole, not of
each part. IMO, something like
if zipped:
extension = "tar.gz"
else:
extension = "tar"
print "Processed %s.%s" % (filename, extension)
is less clear than
print "Processed %s.%s" % (filename, zipped ? "tar.gz" : "tar")
because the bulk of the space is taken up by code that's not central
to what's actually being done. When I look at the first case, the
main thing I see is not the print line; it's the code to select an
extension. When I look at the second case, it's immediately obvious
that the code is printing a status message.
If I want to look at the code closely and see exactly how the status
message is being generated, the second case takes a little more
effort. But most of the time when I'm looking at the code I won't
care about the details of the status message, and the extra bulk (5x
expansion in number of lines for this case) makes it harder to see
what's going on overall.
-Dave
François Pinard
> Pascal, as designed (as a language for newbies) by N. Wirth, had no
> conditional expressions (and no logical operators that ensured
> short-circuiting, either).
If I remember well (that was a while ago), the Pascal language reference
left undecided a few things, like if logical operators were allowing
short-circuiting or not, the order of evaluation of actual arguments (and
irrelevantly, the behaviour of integer division with negative arguments),
meaning that programmers could not rely on the order of evaluation, or the
non-evaluation, when expression evaluations had side effects.
For what it's worth, in the original Pascal implementation, by Urs Amman
(not sure of spelling) under the direction of Niklaus Wirth, logical
operators were evaluated in full and never short-circuited, but once again,
programmers were not allowed to rely on this.
On the machine Pascal was first implemented (CDC 6000 series), jump
instructions were rather costly (time-wise), and so was integer division, so
great lengths were taken in the compiler generator and run-time library to
avoid needing them, as far as possible.
> Pascal was a very deliberate reversion to simplicity from the
> complications of Algol-68 [...]
I think I've heard, at the time, that Niklaus Wirth, who wrote Algol-W by
the time, was invited on the design committee for Algol-68, but slammed the
door relatively early. You might remember that Algol 68 has been, and for
long, notoriously difficult to compile.
Niklaus Wirth mainly selected and merged a few good ideas into what became
Pascal. E. Dijkstra for control structures, C.A.R. Hoare for data
structures, and I guess D. Gries for the compiler design and organisation,
or at least, the compiler seemed to follow Gries a bit slavishingly.
> (I _think_ Algol 60 [...]
Algol 60 design was such that it forced a rather slow run-time in many ways,
and much contributed to the wide spread opinion among computer specialists
that elegance and speed could not live together. Pascal tried to repair
that opinion, and the compiler implementation was very fond on generating
code that runs fast, nearly to the point of exaggeration. This has been
corrected in later versions of the original compiler, especially when the
compiler maintenance was later moved from E.T.H. Zurich into U.S. (through
the doings of Andy Mickle at U. Minnesota? I am not sure), where some speed
was traded in favour of maintainability and better integration with the
operating system. Yet, for a while, Niklaus Wirth has been reluctant to
these changes, despite they had no real effect on the language reference.
--
François Pinard http://www.iro.umontreal.ca/~pinard
David LeBlanc
> What exactly do you mean by "short circuiting conditionals"?
>
> I thought it just meant something like C's ternary operator.
> Algol 60 had something like that. You could say
>
> x = if a>=0 then sqrt(a) else sqrt(-a);
>
> which would take the square root of the absolute value of a.
> Short circuiting just means the non-selected branch doesn't get evaluated.
Incorrect. Short circuiting refers to a complex conditional aborting
evaluation as soon as it fails (technically, as soon as the result is
determinable), as in:
if a > b and c < d:
print e
If a <= b then c will never be evaluated against d: that's the short
circuit. Life gets "interesting" if there is a side effect in the
unevaluated portion of the conditional:
if a > b and c < d():
print e
d() might never get called. Not good if d() does something you depend on.
Dave LeBlanc
Seattle, WA USA
Tim Peters
> ...
> Seems to me:
>
> (a) an initial identifier may constitute the beginning of an
> expression or a statement but the parser can handle it. Why is it an
> issue for 'if'?
It would be the first such case in Python.
> (b) if this is an actual problem for existing Python parsers (I
> don't know if it is or not),
You have the source code. The grammar is in file Grammar/Grammar, and the
makefile knows how to drive Python's parser generator.
> such designs are certainly not beyond the capabilities of
> other (say) 1980s era parser technology.
For that matter, they weren't beyond Fortran's parsing technology in the
50's either.
> (c) parsing is further simplified if different tokens are used for
> expressions vs. statements, ala C, in contrast with Algol60.
>
> Most importantly, adding conditional expressions to the language is NOT
> a technical problem. The principal issues are ideological.
I don't know what that means, but I agree there's no insurmountable
technical problem. As I mentioned last week, Guido already implemented a
ternary operator for Python. His patch is on SourceForge, and I gave a URL
for it last time. He rejected his patch, though. Look up the patch for
more.
James J. Besemer
Tim Peters wrote:
> The distinction between expressions and statements, much stronger in Algol
> 60 than in Python (every Python expression is a Python statement; no Algol
> 60 expression is an Algol 60 statement;
this may be true but I don't think it is relevant.
> a consequence is that if Python were
> to add conditional expressions of the if/then/else form, seeing an initial
> "if" would not be enough to distinguish the expression form from the
> statement form, and that has consequences; [...]
Seems to me:
(a) an initial identifier may constitute the beginning of an expression or a
statement but the parser can handle it. Why is it an issue for 'if'?
(b) if this is an actual problem for existing Python parsers (I don't know if
it is or not), such designs are certainly not beyond the capabilities of
other (say) 1980s era parser technology.
(c) parsing is further simplified if different tokens are used for
expressions vs. statements, ala C, in contrast with Algol60.
Most importantly, adding conditional expressions to the language is NOT a
technical problem. The principal issues are ideological.
Regards
--jb
--
James J. Besemer 503-280-0838 voice
2727 NE Skidmore St. 503-280-0375 fax
Portland, Oregon 97211-6557 mailto:j...@cascade-sys.com
http://cascade-sys.com
Erik Max Francis
> On Thu, 2003-02-06 at 17:19, Mike Meyer wrote:
>
> > Hey, that's what we need to make the people who want an assignment
> > operator happy! Block expressions.
>
> Welcome to Ruby.
I recall a colleague, way back when, who was awfully fond of an
analogous feature in BLISS -- where apparently there was less
distinction between statements and expressions even than in C or similar
modern languages.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ I'll be your strength / I'll be here when you wake up (all right)
\__/ Sweetbox
7 Sisters Productions / http://www.7sisters.com/
Web design for the future.
Carlos Ribeiro
> if a > b and c < d():
> print e
>
> d() might never get called. Not good if d() does something you depend on.
But is just perfect in some cases (common in programs that rely on short
circuiting) where the evaluation of d() depends upon some condition that is
tested first. The usual case is something like this:
if a <> 0 and c < (b/a):
print e
That's just to point out why short-circuiting might be useful. Anyway, it's a
religious debate over the choice of short-circuiting x full evaluation, and
there are *lots* of good arguments from both sides. Performance wise, short
circuiting will be faster, and probably a bit safer in 'normal' situations.
Carlos Ribeiro
Andrew Koenig
David> unevaluated portion of the conditional:
David> if a > b and c < d():
David> print e
David> d() might never get called. Not good if d() does something you
David> depend on.
On the other hand, short-circuiting greatly simplifies the
implementation of a number of commonly used algorithms:
i = 0
while i < len(x) and x[i] != y:
i += 1
Try writing this loop without short-circuiting and see how much more
complicated it becomes.
--
Andrew Koenig, a...@research.att.com, http://www.research.att.com/info/ark
David LeBlanc
David LeBlanc
Seattle, WA USA
> -----Original Message-----
> From: python-l...@python.org
> [mailto:python-l...@python.org]On Behalf Of Carlos Ribeiro
> Sent: Friday, February 07, 2003 3:23
> To: David LeBlanc; pytho...@python.org
> Subject: Re: ternary operator
>
>
> On Friday 07 February 2003 04:15 am, David LeBlanc wrote:
> > if a > b and c < d():
> > print e
> >
> > d() might never get called. Not good if d() does something you
> depend on.
>
> But is just perfect in some cases (common in programs that rely on short
> circuiting) where the evaluation of d() depends upon some
> condition that is
> tested first. The usual case is something like this:
>
> if a <> 0 and c < (b/a):
> print e
>
> That's just to point out why short-circuiting might be useful.
> Anyway, it's a
> religious debate over the choice of short-circuiting x full
> evaluation, and
> there are *lots* of good arguments from both sides. Performance
> wise, short
> circuiting will be faster, and probably a bit safer in 'normal'
> situations.
>
>
> Carlos Ribeiro
>
Andrew Koenig
Then how would you write the following loop?
i = 0;
while i < len(n) and x[i] != y:
i += 1
--
Wojtek Walczak
> David> I think that's POOR programming practice!
>
> Then how would you write the following loop?
>
> i = 0;
> while i < len(n) and x[i] != y:
> i += 1
n = "QQQ"
y = "y"
x = "abcdfghy"
and here's the rest of the script:
# here's your way
i = 0
while i < len(n) and x[i] != y:
i += 1
print i
# the other way ;)
print len(filter(lambda z: z!=y, list(x)[:len(n)]))
...but, well, in almost any case I'd use while loop, and what's _POOR_
for me is top-posting on Usenet rather than using i=0;while ...:... :)
--
[ ] gminick (at) underground.org.pl http://gminick.linuxsecurity.pl/ [ ]
[ "Po prostu lubie poranna samotnosc, bo wtedy kawa smakuje najlepiej." ]
Alex Martelli
Andrew Koenig wrote:
> David> I think that's POOR programming practice!
>
> Then how would you write the following loop?
>
> i = 0;
> while i < len(n) and x[i] != y:
> i += 1
Hmmm, the fact that i<len(n) gives no guarantee that
i is a valid index on x, in general. So, I'm not sure
if you may not perchance mean i<len(x) instead, which
might be a more ordinary case.
If so, and x is a list, then:
i = x.index(y)
is, I think, the best approach in Python.
If x was (for example) a tuple, and/or assuming that n
is not necessarily x but may refer to another sequence
which is known to be no longer than x, then I might
code this as:
for i in range(len(n)):
if x[i] == y: break
or, in Python 2.3 -- if n is actually x, then:
for i, thingy in enumerate(x):
if thingy == y: break
or without the n <-> x identification, then:
for i, thingy in enumerate(x):
if i>=len(n) or thingy == y: break
None of this is meant to deny the usefulness of
the short-circuiting and/or operators. It's just
that there are several attractive alternatives for
this _specific_ case in Python, but of course many
other cases exist where relying on and/or short-
circuit semantics yields the most elegant solution.
Alex
Andrew Koenig
>> Then how would you write the following loop?
>>
>> i = 0;
>> while i < len(n) and x[i] != y:
>> i += 1
Alex> Hmmm, the fact that i<len(n) gives no guarantee that
Alex> i is a valid index on x, in general. So, I'm not sure
Alex> if you may not perchance mean i<len(x) instead, which
Alex> might be a more ordinary case.
Right.
Alex> If so, and x is a list, then:
Alex> i = x.index(y)
Alex> is, I think, the best approach in Python.
But that doesn't really answer the question, does it?
Alex> None of this is meant to deny the usefulness of
Alex> the short-circuiting and/or operators. It's just
Alex> that there are several attractive alternatives for
Alex> this _specific_ case in Python, but of course many
Alex> other cases exist where relying on and/or short-
Alex> circuit semantics yields the most elegant solution.
Right.
Moreover, I think that loops that use "break" statements
are harder to reason about than ones that don't.
Andrew Koenig
Wojtek> print len(filter(lambda z: z!=y, list(x)[:len(n)]))
There are, of course, lots of ways of writing equivalent programs that
are structured completely differently; but those programs don't answer
the question that I'm asking.
David LeBlanc
> From: python-l...@python.org
> [mailto:python-l...@python.org]On Behalf Of Andrew Koenig
> Sent: Friday, February 07, 2003 8:20
> To: pytho...@python.org
> Subject: Re: ternary operator
>
>
I think you missed the point twice: it's not about indexing, it's about
calling a function whose side effects you depend on (always) in a component
of an expression that might not get evaluated.
David LeBlanc
> From: python-l...@python.org
> [mailto:python-l...@python.org]On Behalf Of Wojtek Walczak
> Sent: Friday, February 07, 2003 8:47
> To: pytho...@python.org
> Subject: Re: ternary operator
>
>
> ...but, well, in almost any case I'd use while loop, and what's _POOR_
> for me is top-posting on Usenet rather than using i=0;while ...:... :)
>
I've never quite understood why it's considered rude to top-post, especially
given that most people quote emails verbatim in their reply. I already read
that, and I want the new stuff - why scroll past the old stuff to get to the
new stuff? It does make sense to embed responses when you're responding to
something point by point, but that's not always the form of a reply.
I suspect that if people trimmed email responses, usenet/ml bytes would drop
drastically. I wonder what the spammie hit rate on ">" is? ;)
Andrew Koenig
David> it's about calling a function whose side effects you depend on
David> (always) in a component of an expression that might not get
David> evaluated.
I didn't miss that point.
I think there are two cases that are often confused with each other:
1) Calling a function with side effects that you depend on;
2) Using one expression to guard another--that is, evaluating
one expression to determine whether another is meaningful
before evaluating it.
In general, I think that the first case makes programs harder to
follow, and the second case makes them easier. Of course, there
will always be exceptions, but I think this is true in general.
The difference is that in case (1), the side effects happen somewhere
else (otherwise they wouldn't be side effects), whereas in case 2,
the parts of the computation contribute to the results of the expression
and nothing else.
Alex Martelli
>>> Then how would you write the following loop?
>>>
>>> i = 0;
>>> while i < len(n) and x[i] != y:
>>> i += 1
...
> Alex> i = x.index(y)
> Alex> is, I think, the best approach in Python.
>
> But that doesn't really answer the question, does it?
It answered the literal question you posed (with s/n/x/)
though not the one you meant (we bots are like that;-).
> Moreover, I think that loops that use "break" statements
> are harder to reason about than ones that don't.
Everything else being equal, yes. However, everything
else is rarely equal. In particular, Python's "for" loop is
most often the simplest and most direct way to iterate
on any iterable; the "while" equivalent is lower-level and
less intuitive, more often than not. So, whenever you
need to potentially cease iterating before the end of the
sequence, "break" enters the picture. Consider, for
example, advancing a file to the first line that equals
"xop\n", if any. With for and break:
for aline in thefile:
if aline=="xop\n": break
pretty simple. With while and without break it's, hmmm...:
aline = thefile.readline()
while aline and aline != "xop\n":
aline = thefile.readline()
I don't agree that this is "harder to reason about" than
the for cycle above. The repeated calls to readline, and
the more complicated expression on the while clause,
in my opinion make this more complicated.
The situation is not all that different for the case of (e.g.
assuming x is a tuple):
i = 0
while i < len(n) and x[i] != y:
i += 1
versus:
for i, xi in enumerate(x):
if xi != y: break
the structures are similar to the "iterate on a file" cases.
A for - cum - break has two salient points:
for <variables> in <iterator>:
if <condition-satisfied on variables>: break
you only need to identify and understand "iterator" and
"condition-satisfied". With a while and no break:
<set up initial variables>
while <not finished yet> and not <condition-satisfied>:
<obtain new values for variables>
these statements may require you to identify and
understand as many as four salient points -- the set up,
the not-finished, the condition-satisfied, and the
obtain-new. Even though one of the four is often
trivial enough to ignore, even in those cases the 3:2
ratio in "numbers of salient points you need to identify
and understand" still bids fair to make the "for" easier
even with its break -- and the need to join two
logical expressions (one studying whether the iteration
is finished, one studying whether the current point in
the iteration satisfies a condition) into a longer one with
'and' doesn't make things any simpler -- even when 'and'
short-circuits (as we agree it had better;-).
Alex
Cliff Wells
--
Cliff Wells, Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308 (800) 735-0555 x308
Roger
Roger
(for added emphasis)
>--
>http://mail.python.org/mailman/listinfo/python-list
David LeBlanc
digress ;)
David LeBlanc
Seattle, WA USA
> --
> http://mail.python.org/mailman/listinfo/python-list
David LeBlanc
> From: python-l...@python.org
> [mailto:python-l...@python.org]On Behalf Of Andrew Koenig
> Sent: Friday, February 07, 2003 14:29
> To: whi...@oz.net
> Cc: pytho...@python.org
> Subject: Re: ternary operator
>
>
D'accord! (Oops, sorry, we don't like the French right now - I agree! ;) )
Peter Hansen
seconds of jumping back and forth between the four messages to figure
out what the hell Roger was talking about. He said "explain what?"
and I went looking in your first posting for the question you'd
asked. Of course, it was actually a reply to Cliff's question,
but since Cliff's is quietly hidden in between the two messages, it
wasn't at all clear what was going on. This was aggravated by the
fact that Roger's posting showed up here first, so I hadn't even
seen Cliff's yet.
Basically, the answer (if anyone can still find the question below)
is that for a wide range of very good reasons, *both* top-posting *and*
inadequate pruning of quoted material are extremely rude, as they
force readers to work extra hard to find the context and understand
the post.
If you want to be understood, write clearly, use punctuation and
capitalization conventionally, check your spelling and, oh yeah, prune
unnecessary quoted material and *don't top-post*. :-)
-continuing-to-call-the-kettle-black-ly yr's,
Peter
Cliff Wells
The explanation was implicit in the difficulty of following the
conversation without referring back to previous posts. As you can see,
each top-post adds to the confusion, especially when intermixed with
other posting styles. Had all of us been following the rule of *not*
top-posting (and trimming our posts, as I'm intentionally not doing here
so as to preserve the mess created by top-posting), the logical flow of
the conversation would still be intact.
Carlos Ribeiro
> I think that's POOR programming practice!
David,
I'll just repeat what I said: the option to rely (or not - after all, it
depends on the actual language and/or implementation) on short circuit
evaluation is pretty much a religious debate. Some people think it's poor
programming practice, others think that it is the obvious way of doing stuff.
As for myself, being an old Pascal/Delphi addict, I'm used to (relying on)
short-circuiting expressions, but I avoid it if I feel it will make the code
less clear.
Carlos Ribeiro
crib...@mail.inet.com.br
> David LeBlanc
> Seattle, WA USA
>
> > -----Original Message-----
> > From: python-l...@python.org
> > [mailto:python-l...@python.org]On Behalf Of Carlos Ribeiro
> > Sent: Friday, February 07, 2003 3:23
> > To: David LeBlanc; pytho...@python.org
> > Subject: Re: ternary operator
> >
Andrew Koenig
Carlos> (relying on) short-circuiting expressions, but I avoid it if I
Carlos> feel it will make the code less clear.
The original definition of Pascal did not short-circuit expressions.
Carel Fellinger
...
> As for myself, being an old Pascal/Delphi addict, I'm used to (relying on)
> short-circuiting expressions, but I avoid it if I feel it will make the code
> less clear.
What hideous dialect of Pascal did you grew up with that made you
believe short-circuiting semantics to be defined in the language?
--
groetjes, carel
Carlos Ribeiro
Just a clarification. I never thought that this was about to become a
quasi-flame-feast, and I just wanted to point out that:
a) there are different evaluation modes for logical expressions, short
circuiting being only one of the options, AND ...
b) that the ternary operator is (by definition) a short-circuiting
alternative, AND ...
c) that it can't be properly simulated by a function, because functions
evaluate their arguments at call time, UNLESS ...
d) you have something called lazy evaluation ...
e) which is something Python do not support.
As far as Pascal is concerned, I *know* that short-circuiting is not part of
the language. As I said above, I was an old Pascal/Delphi addict, from what
you can infer that I used Turbo Pascal, and then Borland Pascal, and later
Borland Delphi - all of which offering short-circuiting evaluation. If that's
a capital sin, please forgive me. I give up.
Carlos Ribeiro
crib...@mail.inet.com.br
Andrew Koenig
Carlos> evaluate their arguments at call time, UNLESS ...
Carlos> d) you have something called lazy evaluation ...
Carlos> e) which is something Python do not support.
Not directly, anyway. You could do this:
result iff(<cond>, lambda: expr1, lambda: expr2)
but in my opinion, the need to do it this way is a strong argument
in favor of the PEP.
Carel Fellinger
> On Saturday 08 February 2003 01:22 am, Carel Fellinger wrote:
> > What hideous dialect of Pascal did you grew up with that made you
> > believe short-circuiting semantics to be defined in the language?
>
> Just a clarification. I never thought that this was about to become a
> quasi-flame-feast, and I just wanted to point out that:
It was never ment that way:( Originally my post had a smiley, but silly
me thought there ought to be a question mark too and I dropped the smiley.
This was one of the things that were not well defined in the early
days of Pascal, and IIRC even in Jensen and Wirth 2e edition this
still is undefined, so it better be ment rather jokingly too:)
--
groetjes, carel
Mike Meyer
> I've never quite understood why it's considered rude to top-post, especially
> given that most people quote emails verbatim in their reply.
Quoting email verbatim is also rude. If I really want the full text of
what you are replying to, I can find it on google.
The problem with top posting is that it makes following the
*conversation* almost impossible. You wind up skimming down over most
of the text, then reading down, then skimming over what you just read
and over what you're about to read, reading down, and then doing that
over and over again.
<mike
--
Mike Meyer <m...@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Wojtek Walczak
>> -----Original Message-----
>> From: python-l...@python.org
>> [mailto:python-l...@python.org]On Behalf Of Wojtek Walczak
>> Sent: Friday, February 07, 2003 8:47
>> To: pytho...@python.org
>> Subject: Re: ternary operator
...those lines above are rude and useless too...
> I've never quite understood why it's considered rude to top-post, especially
> given that most people quote emails verbatim in their reply. I already read
> that, and I want the new stuff - why scroll past the old stuff to get to the
> new stuff? It does make sense to embed responses when you're responding to
> something point by point, but that's not always the form of a reply.
Well, when you're (I mean - anybody ;)) reading lots of threads in the same
time, sometimes you can forget what's the case in that concrete response.
If it's top-posted then you need to go below to read those ugly uncut messages
and then go back and here's the waste of time. When someone leaves just
a piece of text above, it's (in most cases) a great reminder.
That's my way of looking at top-posting, but except of that I like order
(at least when using a computer ;)), traditions and besides of that, simply,
a good taste.
EOT - it was discussed billions of times.
Wolfgang Strobl
>It's been said that Algol 60 is one of the few languages so well
>designed that it improved not only on its predecessors, but on most of
>its successors as well.
A similar remark could be made about Simula67.
--
Wir danken für die Beachtung aller Sicherheitsbestimmungen
Andrew Koenig
Dennis> or
Dennis> vs
Dennis> or else
Indeed -- this is the best evidence that Ada is the result of a military
project. In what other language is "or else" an operator?
Alex Martelli
...
> Indeed -- this is the best evidence that Ada is the result of a military
> project. In what other language is "or else" an operator?
Taking the question literally: several cognate ("Pascal-ish syntax")
languages, such as Eiffel and various dialects of Pascal (Sun Pascal,
GNU Pascal). (Not to spoil the nice pun, just for completeness...).
Alex
Dan Bishop
> Dennis> Similar for
>
> Dennis> or
> Dennis> vs
> Dennis> or else
>
> Indeed -- this is the best evidence that Ada is the result of a military
> project. In what other language is "or else" an operator?
Babbage (http://www.tlc-systems.com/babbage.htm) uses it as a
"conditional threat" ("Add these two numbers OR ELSE!").
But if you meant whether there's an "or else" in a language that
people actually program in, I don't know of any.
Mike Meyer
> Andrew Koenig <a...@research.att.com> wrote in message news:<yu99smuy...@europa.research.att.com>...
> > Dennis> Similar for
> >
> > Dennis> or
> > Dennis> vs
> > Dennis> or else
> >
> > Indeed -- this is the best evidence that Ada is the result of a military
> > project. In what other language is "or else" an operator?
> But if you meant whether there's an "or else" in a language that
> people actually program in, I don't know of any.
Since people actually program in Ada, that's one. Eiffel also uses "or
else" for short-circuit booleans.
Martin Maney
> Andrew Koenig wrote:
>
>>>> Then how would you write the following loop?
>>>>
>>>> i = 0;
>>>> while i < len(n) and x[i] != y:
>>>> i += 1
> ...
>> Alex> i = x.index(y)
>> Alex> is, I think, the best approach in Python.
>>
>> But that doesn't really answer the question, does it?
>
> It answered the literal question you posed (with s/n/x/)
> though not the one you meant (we bots are like that;-).
But it didn't, really. This suggested replacement has dramatically
different behavior for some input. Your other "equivalent" fails,
differently, for the same case: when y is not in x.
> aline = thefile.readline()
> while aline and aline != "xop\n":
> aline = thefile.readline()
>
> I don't agree that this is "harder to reason about" than
> the for cycle above. The repeated calls to readline, and
> the more complicated expression on the while clause,
> in my opinion make this more complicated.
So let me see if I understand: you are saying that the more complicated
form is NOT more difficult to understand, that Python's alleged raison
d'etre is a sham, and the PSU will not come along and sto
Sheila King
in comp.lang.python in article
<mailman.1044656839...@python.org>:
> I've never quite understood why it's considered rude to top-post, especially
> given that most people quote emails verbatim in their reply. I already read
> that, and I want the new stuff - why scroll past the old stuff to get to the
> new stuff? It does make sense to embed responses when you're responding to
> something point by point, but that's not always the form of a reply.
Here are several references which explain why the inline quoting is
preferable. It really boils down to actual discussions taking place, in
which many people may be participating. Without properly nesting the quoted
material, it can be extremely difficult for someone reading the post later
to figure out the attributions and their source.
http://www.xs4all.nl/%7ewijnands/nnq/nquote.html
http://www.river.com/users/share/etiquette/#inline
http://www.mindspring.com/~frites/repl.htm#samp
http://homepage.ntlworld.com/g.mccaughan/g/remarks/uquote.html
http://www.cs.tut.fi/~jkorpela/usenet/brox.html
Hope these additional sources of information make the reasons clearer for
you.
--
Sheila King
http://www.thinkspot.net/sheila/
http://www.k12groups.org/
Mel Wilson
Alex Martelli <al...@aleax.it> wrote:
>Trust me -- I know several excellent Cobol experts and ternary
>is NOT what they're looking for. "PICTURE" and other uses of
>fixed-point are much more likely to be it, or maybe (though that
>still baffles me a bit) "ADD a TO b GIVING c" as an alternative
>to "weird, algebraic" (sic) "c = a + b" ...
As a COBOL programmer, I want
if a < 3:
less_than_3_thing ()
elif 7:
less_than_7_thing ()
elif 92:
some_other_thing ()
else:
not_appearing_in_the_above_code ().
Python does COMPLETELY the WRONG THING with this.
Regards. Mel.
And now, back to the PEP 308 threads.
Delaney, Timothy C (Timothy)
>
> As a COBOL programmer, I want
>
> if a < 3:
> less_than_3_thing ()
> elif 7:
> less_than_7_thing ()
> elif 92:
> some_other_thing ()
> else:
> not_appearing_in_the_above_code ().
I must say, I don't remember that from my two weeks of COBOL programming on work experience for school back in 1989(?).
> Python does COMPLETELY the WRONG THING with this.
<wink> That's just sick.
Tim Delaney
James J. Besemer
Delaney, Timothy C (Timothy) wrote:
> I must say, I don't remember that from my two weeks of COBOL
> programming on work experience for school back in 1989(?).
I thought the cobol way of doing things was (partial excerpt):
if user_address = "1700 NW 3rd Street":
send_bill_to_1700_NW_3rd_street()
elif user_address = "1701 NW 3rd Street":
send_bill_to_1701_NW_3rd_street()
elif user_address = "1702 NW 3rd Street":
send_bill_to_1702_NW_3rd_street()
elif user_address = "1703 NW 3rd Street":
send_bill_to_1703_NW_3rd_street()
elif user_address = "1704 NW 3rd Street":
send_bill_to_1704_NW_3rd_street()
elif user_address = "1706 NW 3rd Street":
send_bill_to_1706_NW_3rd_street()
(etc.)
JUST KIDDING!!!! ;o) !!!
Then there's the new Cobol with OO extensions, called
"ADD ONE TO COBOL" ;o)
Sorry, old jokes, couldn't resist.
Regards
--jb
--
James J. Besemer 503-280-0838 voice
2727 NE Skidmore St. 503-280-0375 fax
Portland, Oregon 97211-6557 mailto:j...@cascade-sys.com
http://cascade-sys.com
John Roth
"Delaney, Timothy C (Timothy)" <tdel...@avaya.com> wrote in message
news:mailman.104493677...@python.org...
Tim Delaney
Sigh. It's also wrong - whoever wrote the original didn't know COBOL!
While I've forgotten the syntax, it has a fully functional case style
construct (SELECT)?.
John Roth
Alex Martelli
...
> Sigh. It's also wrong - whoever wrote the original didn't know COBOL!
> While I've forgotten the syntax, it has a fully functional case style
> construct (SELECT)?.
As I recall, SELECT associates filenames with datasets -- I don't
think that's the one you mean. Maybe EVALUATE, as in:
EVALUATE some-expression
WHEN 1 ...
WHEN 2 THROUGH 17 ...
WHEN OTHER ...
END-EVALUATE.
if my memory's not playing tricks. There's also some weird
form "EVALUATE this ALSO that ... WHEN 12 ALSO 23 ..." but
I don't think anybody would claim that's readable or clear...
and you could have expressions in the WHEN, I believe, not
just constants... I'd better stop before some real cobolist
starts laughing too hard, I only learned Cobol in a couple of
days because it was the only alternative to a horrid non
procedural thing called "cross-system product" that I could
use to help a local University make some mods to their
accounting system, and that was 15 years ago...!-)
Alex