This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: conditional expression (if-then-else)
Type: Stage:
Components: Interpreter Core Versions:
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: gvanrossum Nosy List: gvanrossum, loewis, tim.peters
Priority: low Keywords: patch

Created on 2001-10-15 18:59 by gvanrossum, last changed 2022-04-10 16:04 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
conditional.txt gvanrossum, 2001-10-15 19:00
conditional-2.txt gvanrossum, 2001-10-15 21:01 Paren-less "else if"
Messages (9)
msg37860 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2001-10-15 18:59
Here's an implementation of conditional expressions of
the form

    if <test> then <test> else <test>

It's hairier than expected because I'm trying to
require you to put parentheses around it in some cases
but not in others.

This still lacking:

- a PEP to motivate and explain it
- documentation
- tests
- needed changes to Modules/parsermodule.c

After applying this patch, you must regenerate the
grammar; the Unix Makefile and the current CVS version
of the Windows project file do this automatically.
msg37861 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2001-10-15 19:22
Logged In: YES 
user_id=31435

FYI, the grammar is not regenerated by magic on Windows.  I 
very recently checked in Parser/grammar.mak (a Windows 
nmake file), which you can use "by hand" (read the comments 
at the top of the file) to regenerate the grammar if you 
know that's needed.
msg37862 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2001-10-15 19:34
Logged In: YES 
user_id=21627

Would the grammar become simpler if the syntax was

if <test> then <test> else <test> fi

?
msg37863 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2001-10-15 19:44
Logged In: YES 
user_id=31435

Martin, I don't think so.  "The problem" is ensuring the 
parser can distinguish a conditional expression from an if 
statement, as they both begin with "if".  A left paren 
rules out an if-statement.  If the conditional expression 
*began* with "fi", no problem <wink>.
msg37864 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2001-10-15 19:47
Logged In: YES 
user_id=6380

The 'fi' would disambiguate binary operators following the
else part. But I find it very unpythonic: we don't have
Algol-68 style reversed closing keywords anywhere else, and
when you squint you don't see the structure.
msg37865 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2001-10-15 20:04
Logged In: YES 
user_id=6380

Somthing to think about: should this support 'elif'?  Like
this:

  p = if x==1 then 'one' elif x==2 then 'two' elif x==3 then
'three' else 'many'

With the current patch that would have to be written using
ugly extra parentheses:

  p = if x==1 then '1' else (if x==2 then '2' else (if x==3
then '3' else '*'))

It would be easy enough to allow these parentheses to be
omitted: just change the conditional to 'if' test 'then'
test 'else' (test | conditional).

Allowing 'elif' might then not be needed.
msg37866 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2001-10-15 20:50
Logged In: YES 
user_id=31435

About elif, I channeled you as leaving it out deliberately 
<wink>.  A long chain of these is probably crying out for a 
dict lookup instead:

p = {1: 'one', 2: 'two', 3: 'three'}.get(x, 'many')

where the dict literal wouldn't really be written inline.

Short of adding elif, though (OK by me), the "extra" parens 
needed using "else if" instead must go.
msg37867 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2001-10-15 21:01
Logged In: YES 
user_id=6380

OK, conditional-2.txt is a patch that includes the
paren-less "else if", as well as the graminit.[ch] diffs.
msg37868 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2001-10-16 20:09
Logged In: YES 
user_id=6380

The more I think about this, the less I like it -- mostly
because I cannot find decent examples in the std library
that would benefit from this...
History
Date User Action Args
2022-04-10 16:04:31adminsetgithub: 35330
2001-10-15 18:59:52gvanrossumcreate