On 3/6/06, Thomas Wouters <thomas@python.org> wrote:

On 3/6/06, Jim Jewett <jimjjewett@gmail.com> wrote:

...

level = 0 if "absolute_import" in self.futures else -1

...

Mentally, I can't help parsing that as "level = 0" plus comments that turn out to be code that triggers backtracking.

...

I think that adding parentheses would help ...

...

level = (0 if "absolute_import" in self.futures else -1)

I'm not sure, are you suggesting the grammar/parser enforces it that way, or that it should be in PEP-8?

I would prefer that the grammar enforce it, but putting it in PEP 8 would be a half-way measure. I can't imagine an expression small enough that the parentheses really hurt. var = t if c else f var = (t if c else f) In PEP 8, I would even go so far as to recommend parentheses around the three sub-expressions if they contain any internal whitespace, but I don't think the grammar should enforce that.

(I still can't help but go 'yecchh' whenever I see the code. It looks like Perl's 'expr if expr' form, but it behaves quite different. Right now, removing if/else expressions still looks like the best solution, to me :->

Yah, that sounds uncontroversial. :D -jJ

Steve Holden wrote:

Contrast with the bleeding obvious:

level = 0 if "absolute_import" in self.futures: level = -1

regards Steve

The issue that spawned the necessity of a ternary operator in the first place was that this syntax is not usable at all in quite a few situations like, say, list comprehensions...

Morel Xavier wrote:

Steve Holden wrote:

...

Contrast with the bleeding obvious:

level = 0 if "absolute_import" in self.futures: level = -1

regards Steve

...

The issue that spawned the necessity of a ternary operator in the first place was that this syntax is not usable at all in quite a few situations like, say, list comprehensions...

And of course the example I criticized was a list comprehension (not). The fact that ternary operators improve some features isn't an excuse for using them when they actually decrease readability. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd www.holdenweb.com Love me, love my blog holdenweb.blogspot.com

[Jim Jewett]

...

...

I think that adding parentheses would help, by at least signalling that the logic is longer than just the next (single) expression.

level = (0 if "absolute_import" in self.futures else -1)

[Steve Holden]

...

Contrast with the bleeding obvious:

level = 0 if "absolute_import" in self.futures: level = -1

or even, if a certain obscurity is desirable:

level = - ("absolute_import" in self.futures)

In honor of Peter Naur receiving the 2005 Turing Award: <http://campus.acm.org/public/pressroom/press_releases/3_2006/turing_3_01_200...> and remembering Python's Algol roots, I'd like to constrast it with the truly obvious: level = (if "absolute_import" in self.futures then 0 else -1) That way also has the minor advantage of computing the same value for `level` as Jim's code ;-) [Joe Smith]

Wait a second.

I may be just a user but if the above is correct then that syntax needs to die! There is no logical reason for "XX if YY else ZZ" to be roughly equivlent to: "if (YY) then {ZZ} else {XX}" , but AFAICT that is pretty much the way you expanded that.

Ya, Steve just got it backwards. "(X if Y else Z)" is the same as "(if Y then X else Z)", except for the excessive novelty. The obvious spelling would require making "then" a keyword, which is actually OK with everyone :-)

I hope I misunderstood, or that there was a typo in a post.

You were lucky this time, bucko, but don't ever go questioning a python-dev regular again ;-)

On 3/6/06, Alex Martelli <aleaxit@gmail.com> wrote:

On Mar 6, 2006, at 9:17 AM, Jim Jewett wrote: ...

...

I think that adding parentheses would help, by at least signalling that the logic is longer than just the next (single) expression.

level = (0 if "absolute_import" in self.futures else -1)

+1 (just because I can't give it +3.1415926...!!!). *Mandatory* parentheses make this form MUCH more readable.

Recent language features seem to be suffereing from excessive parenthesisitis. I worry that people will stop remembering which expressions requirement parens in which context. Perhaps the solution is to require parens around all expressions, a simple consistent rule. If so, then adding parens around all statements is a fairly natural extension, which solves a number of problems like how to make a richer lambda. Jeremy

Paul Moore wrote:

On 3/7/06, Jeremy Hylton <jeremy@alum.mit.edu> wrote:

...

...

...

I think that adding parentheses would help, by at least signalling that the logic is longer than just the next (single) expression.

level = (0 if "absolute_import" in self.futures else -1) +1 (just because I can't give it +3.1415926...!!!). *Mandatory*

On Mar 6, 2006, at 9:17 AM, Jim Jewett wrote: ... parentheses make this form MUCH more readable. Recent language features seem to be suffereing from excessive

On 3/6/06, Alex Martelli <aleaxit@gmail.com> wrote: parenthesisitis.

Agreed. Mandatory parentheses purely for readability are ultimately futile - I bet I can write unreadable code even if the parens were required :-)))))))))))))))))))))))))

The parentheses around genexps were (AFAICT) different - without them, the grammar was ambiguous, so some way of disambiguating was needed.

+0 for mentioning parens around conditional expressions in PEP 8. But it's aready covered by the general "code should be readable" in my view.

Agreed - and often the best way to make a conditional expression readable is to not use it in the first place, which is a concept that an official policy on parentheses may mask. And then there's the question of how to parenthesise chained conditional expressions. Mandatory parentheses in that case would make me wonder if I was writing a certain language that isn't Python. . . Given that the main reason PEP 308 was finally implemented was to provide OOWTDI for conditional expressions (instead of the handful of not-at-all-obvious and not-quite-right-either workarounds that had developed in their absence), I expect to see of rush of enthusiastic overuse of the new expression, which will eventually settle down as everyone remembers that not every problem is a nail to be hit with the shiny new hammer ;) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org

Jim Jewett wrote:

On 3/7/06, Paul Moore <p.f.moore@gmail.com> wrote:

...

The parentheses around genexps were (AFAICT) different - without them, the grammar was ambiguous, so some way of disambiguating was needed.

The out-of-order evaluation is a very large change, because now we have a situation where normal parsing completes an expression, but needs to avoid evaluating it, just in case.

Currently, we can write:

>>> if False: >>> print r >>> else: >>> print 6

6

>>> r

Traceback (most recent call last): File "<pyshell#14>", line 1, in -toplevel- r NameError: name 'r' is not defined

In the above example, r doesn't get evaluated because the if ahead of it says to skip that branch. But with conditional expressions, that flow control is changed from *later* in the program.

I don't think we'll see the equivalent of Intercal Suck Points anywhere but intentionally obfuscated code, but I do expect to see:

>>> side_effect() if condition

In fact, I think the below examples are reasonable uses that do a better job of expressing intent than the if statement would. I just don't like the mental backtrack they require, and would like some sort of advance warning. Parentheses at least tell me "You're not done yet; keep reading."

>>> ack(r,r) if r not in cache

>>> log(message) if error_flag

I think you've misunderstood the nature of the change. HTe new conditionals are *expressions*, they aren't postfix conditionals for statements. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd www.holdenweb.com Love me, love my blog holdenweb.blogspot.com

Paul Moore wrote:

+0 for mentioning parens around conditional expressions in PEP 8. But it's aready covered by the general "code should be readable" in my view.

Indeed. Writing readable code is ultimately the responsibility of the person doing the writing. It's enough that you *can* put parentheses around things if it helps readability. -- Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | greg.ewing@canterbury.ac.nz +--------------------------------------+

"Greg Ewing" <greg.ewing@canterbury.ac.nz> wrote in message news:440E2614.8050508@canterbury.ac.nz...

Jeremy Hylton wrote:

...

Perhaps the solution is to require parens around all expressions, a simple consistent rule.

I actually designed a language with that feature once. It was an exercise in minimality, with hardly anything built-in -- all the arithmetic operators, etc. were defined in the language.

A result was that there was no built-in notion of precedence, and my solution was to require parentheses around every infix operation. So instead of

dsq = b * b - 4 * a * c

you would have had to write

dsq = ((b * b) - ((4 * a) * c))

I never got an implementation working well enough to find out how much of a disaster this would have been to use, though. :-)

Well the original was almost certainly a tongue-in-cheek reference to LISP. LISP was a disaster to use, so I doubt your language would have been any worse. The way one identifies a lisp programmer is to find the person whose paren keys have worn competely off their keyboard. :D

Joe Smith wrote:

LISP was a disaster to use, so I doubt your language would have been any worse.

At least Lisp would let you say (* 4 a c) and not force you to write (* (* 4 a) c) My language would not have been so forgiving, unless you were willing to define a bunch of different * functions with different numbers of parameters. BTW, I did use Lisp and Scheme fairly heavily for a period, and didn't find them to be disasters -- at least not because of the parens. Greg

On 3/6/06, Thomas Wouters <thomas@python.org> wrote:

On 3/6/06, Jim Jewett <jimjjewett@gmail.com> wrote:

...

level = 0 if "absolute_import" in self.futures else -1

...

Mentally, I can't help parsing that as "level = 0" plus comments that turn out to be code that triggers backtracking.

...

I think that adding parentheses would help ...

...

level = (0 if "absolute_import" in self.futures else -1)

I'm not sure, are you suggesting the grammar/parser enforces it that way, or that it should be in PEP-8?

I would prefer that the grammar enforce it, but putting it in PEP 8 would be a half-way measure. I can't imagine an expression small enough that the parentheses really hurt. var = t if c else f var = (t if c else f) In PEP 8, I would even go so far as to recommend parentheses around the three sub-expressions if they contain any internal whitespace, but I don't think the grammar should enforce that.

(I still can't help but go 'yecchh' whenever I see the code. It looks like Perl's 'expr if expr' form, but it behaves quite different. Right now, removing if/else expressions still looks like the best solution, to me :->

Yah, that sounds uncontroversial. :D -jJ

Steve Holden wrote:

Contrast with the bleeding obvious:

level = 0 if "absolute_import" in self.futures: level = -1

regards Steve

The issue that spawned the necessity of a ternary operator in the first place was that this syntax is not usable at all in quite a few situations like, say, list comprehensions...

Morel Xavier wrote:

Steve Holden wrote:

...

Contrast with the bleeding obvious:

level = 0 if "absolute_import" in self.futures: level = -1

regards Steve

...

The issue that spawned the necessity of a ternary operator in the first place was that this syntax is not usable at all in quite a few situations like, say, list comprehensions...

And of course the example I criticized was a list comprehension (not). The fact that ternary operators improve some features isn't an excuse for using them when they actually decrease readability. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd www.holdenweb.com Love me, love my blog holdenweb.blogspot.com

[Jim Jewett]

...

...

I think that adding parentheses would help, by at least signalling that the logic is longer than just the next (single) expression.

level = (0 if "absolute_import" in self.futures else -1)

[Steve Holden]

...

Contrast with the bleeding obvious:

level = 0 if "absolute_import" in self.futures: level = -1

or even, if a certain obscurity is desirable:

level = - ("absolute_import" in self.futures)

In honor of Peter Naur receiving the 2005 Turing Award: <http://campus.acm.org/public/pressroom/press_releases/3_2006/turing_3_01_200...> and remembering Python's Algol roots, I'd like to constrast it with the truly obvious: level = (if "absolute_import" in self.futures then 0 else -1) That way also has the minor advantage of computing the same value for `level` as Jim's code ;-) [Joe Smith]

Wait a second.

I may be just a user but if the above is correct then that syntax needs to die! There is no logical reason for "XX if YY else ZZ" to be roughly equivlent to: "if (YY) then {ZZ} else {XX}" , but AFAICT that is pretty much the way you expanded that.

Ya, Steve just got it backwards. "(X if Y else Z)" is the same as "(if Y then X else Z)", except for the excessive novelty. The obvious spelling would require making "then" a keyword, which is actually OK with everyone :-)

I hope I misunderstood, or that there was a typo in a post.

You were lucky this time, bucko, but don't ever go questioning a python-dev regular again ;-)

On 3/6/06, Alex Martelli <aleaxit@gmail.com> wrote:

On Mar 6, 2006, at 9:17 AM, Jim Jewett wrote: ...

...

I think that adding parentheses would help, by at least signalling that the logic is longer than just the next (single) expression.

level = (0 if "absolute_import" in self.futures else -1)

+1 (just because I can't give it +3.1415926...!!!). *Mandatory* parentheses make this form MUCH more readable.

Recent language features seem to be suffereing from excessive parenthesisitis. I worry that people will stop remembering which expressions requirement parens in which context. Perhaps the solution is to require parens around all expressions, a simple consistent rule. If so, then adding parens around all statements is a fairly natural extension, which solves a number of problems like how to make a richer lambda. Jeremy

Paul Moore wrote:

On 3/7/06, Jeremy Hylton <jeremy@alum.mit.edu> wrote:

...

...

...

I think that adding parentheses would help, by at least signalling that the logic is longer than just the next (single) expression.

level = (0 if "absolute_import" in self.futures else -1) +1 (just because I can't give it +3.1415926...!!!). *Mandatory*

On Mar 6, 2006, at 9:17 AM, Jim Jewett wrote: ... parentheses make this form MUCH more readable. Recent language features seem to be suffereing from excessive

On 3/6/06, Alex Martelli <aleaxit@gmail.com> wrote: parenthesisitis.

Agreed. Mandatory parentheses purely for readability are ultimately futile - I bet I can write unreadable code even if the parens were required :-)))))))))))))))))))))))))

The parentheses around genexps were (AFAICT) different - without them, the grammar was ambiguous, so some way of disambiguating was needed.

+0 for mentioning parens around conditional expressions in PEP 8. But it's aready covered by the general "code should be readable" in my view.

Agreed - and often the best way to make a conditional expression readable is to not use it in the first place, which is a concept that an official policy on parentheses may mask. And then there's the question of how to parenthesise chained conditional expressions. Mandatory parentheses in that case would make me wonder if I was writing a certain language that isn't Python. . . Given that the main reason PEP 308 was finally implemented was to provide OOWTDI for conditional expressions (instead of the handful of not-at-all-obvious and not-quite-right-either workarounds that had developed in their absence), I expect to see of rush of enthusiastic overuse of the new expression, which will eventually settle down as everyone remembers that not every problem is a nail to be hit with the shiny new hammer ;) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org

Jim Jewett wrote:

On 3/7/06, Paul Moore <p.f.moore@gmail.com> wrote:

...

The parentheses around genexps were (AFAICT) different - without them, the grammar was ambiguous, so some way of disambiguating was needed.

The out-of-order evaluation is a very large change, because now we have a situation where normal parsing completes an expression, but needs to avoid evaluating it, just in case.

Currently, we can write:

>>> if False: >>> print r >>> else: >>> print 6

6

>>> r

Traceback (most recent call last): File "<pyshell#14>", line 1, in -toplevel- r NameError: name 'r' is not defined

In the above example, r doesn't get evaluated because the if ahead of it says to skip that branch. But with conditional expressions, that flow control is changed from *later* in the program.

I don't think we'll see the equivalent of Intercal Suck Points anywhere but intentionally obfuscated code, but I do expect to see:

>>> side_effect() if condition

In fact, I think the below examples are reasonable uses that do a better job of expressing intent than the if statement would. I just don't like the mental backtrack they require, and would like some sort of advance warning. Parentheses at least tell me "You're not done yet; keep reading."

>>> ack(r,r) if r not in cache

>>> log(message) if error_flag

I think you've misunderstood the nature of the change. HTe new conditionals are *expressions*, they aren't postfix conditionals for statements. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd www.holdenweb.com Love me, love my blog holdenweb.blogspot.com

Paul Moore wrote:

+0 for mentioning parens around conditional expressions in PEP 8. But it's aready covered by the general "code should be readable" in my view.

Indeed. Writing readable code is ultimately the responsibility of the person doing the writing. It's enough that you *can* put parentheses around things if it helps readability. -- Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | greg.ewing@canterbury.ac.nz +--------------------------------------+

"Greg Ewing" <greg.ewing@canterbury.ac.nz> wrote in message news:440E2614.8050508@canterbury.ac.nz...

Jeremy Hylton wrote:

...

Perhaps the solution is to require parens around all expressions, a simple consistent rule.

I actually designed a language with that feature once. It was an exercise in minimality, with hardly anything built-in -- all the arithmetic operators, etc. were defined in the language.

A result was that there was no built-in notion of precedence, and my solution was to require parentheses around every infix operation. So instead of

dsq = b * b - 4 * a * c

you would have had to write

dsq = ((b * b) - ((4 * a) * c))

I never got an implementation working well enough to find out how much of a disaster this would have been to use, though. :-)

Well the original was almost certainly a tongue-in-cheek reference to LISP. LISP was a disaster to use, so I doubt your language would have been any worse. The way one identifies a lisp programmer is to find the person whose paren keys have worn competely off their keyboard. :D

Joe Smith wrote:

LISP was a disaster to use, so I doubt your language would have been any worse.

At least Lisp would let you say (* 4 a c) and not force you to write (* (* 4 a) c) My language would not have been so forgiving, unless you were willing to define a bunch of different * functions with different numbers of parameters. BTW, I did use Lisp and Scheme fairly heavily for a period, and didn't find them to be disasters -- at least not because of the parens. Greg