5 ms·

Exactly. I prefer this a lot more to at least avoid using else: x = 5 if condition(): x = 4

da39a3ee 5y ago
No, that's not good. If condition() is true, x shouldn't take the value 5, even temporarily. The combination of (x = 5, condition()) is inconsistent state (using the word "consistent" in the same sense as the C in ACID). It really is clearest and safest to avoid inconsistent state, even if is only transient. There are so many ways programs can be wrong; no need to deliberately create inconsistent state when there's no need to.
chriswarbo 5y ago
In your version, we need to check the definition of 'condition', to see whether the 'x = 5' statement has any affects on its execution. The ternary won't assign the variable until we know its value. Also, your version isn't safe to use with objects (e.g. 'myObject.x = ...'), since the initial assignment could trigger arbitrary code (properties, __setattr__, etc.). Also, your version isn't safe to use when the right-hand-side has effects, e.g. x = fetch_config_url() if remote else read_config_file()
- version_five 5y ago
  Can't be used in list comprehension either
Zababa 5y ago
My favorite way to write that is with expression oriented langauges. Example in OCaml: x = if condition() then 5 else 4 I dislike how the regular order of if is changed when used as an expression. I don't know how you could retrofit that into existing Python tough. Probably a consequence of defining blocks with whitespaces.
- kbenson 5y ago
  Yeah, Python's willingness to break up conceptual concepts into separate parts of an expression such that you might need to backtrack while reading has always seemed an odd choice to me, exemplified by list comprehensions, especially when nested.
- mixmastamyk 5y ago
  It is simply a design choice, the common value is given first. Comprehensions in Py are the same.
  - Zababa 5y ago
    Sure it's a design choice but, quoting the Zen of Python: > Special cases aren't special enough to break the rules. > There should be one-- and preferably only one --obvious way to do it. Both are broken by the existance of 2 if syntaxes depending on the context.
  - DonHopkins 5y ago
    But when you write "condition ? first : second" or "(if condition first second)", the first common value is still given before the second uncommon value, so what's the advantage of putting the condition BETWEEN first and second, instead of BEFORE? After all, the condition has to be EVALUATED first before deciding which one to use. Infix "if" conditions just scramble up the order of evaluation from the order of program source code.
    - mixmastamyk 5y ago
      The argument is that the most common value should be first and the rest can be thought of as rare and almost ignored. I don’t always agree, but still prefer it to C syntax which I have to look up every time.
joshuamorton 5y ago
To add to the cacaphony of counterarguments to this, this can introduce nonobvious bugs when refactoring. If the condition-guarded statement is nontrivial and you remove the assignment, everything stays valid. If otoh you use a ternary or if x: y = 1 else: y = 2 If you now delete the else block or something (like the assignment from a larger else block), a linter can warn you that y is undefined. Otherwise you'd need a test to ensure correctness.

No, that's not good. If condition() is true, x shouldn't take the value 5, even temporarily. The combination of (x = 5, condition()) is inconsistent state (using the word "consistent" in the same sense as the C in ACID). It really is clearest and safest to avoid inconsistent state, even if is only transient. There are so many ways programs can be wrong; no need to deliberately create inconsistent state when there's no need to.

chriswarbo 5y ago

In your version, we need to check the definition of 'condition', to see whether the 'x = 5' statement has any affects on its execution. The ternary won't assign the variable until we know its value. Also, your version isn't safe to use with objects (e.g. 'myObject.x = ...'), since the initial assignment could trigger arbitrary code (properties, __setattr__, etc.). Also, your version isn't safe to use when the right-hand-side has effects, e.g. x = fetch_config_url() if remote else read_config_file()

version_five 5y ago
Can't be used in list comprehension either

Zababa 5y ago

My favorite way to write that is with expression oriented langauges. Example in OCaml: x = if condition() then 5 else 4 I dislike how the regular order of if is changed when used as an expression. I don't know how you could retrofit that into existing Python tough. Probably a consequence of defining blocks with whitespaces.

kbenson 5y ago
Yeah, Python's willingness to break up conceptual concepts into separate parts of an expression such that you might need to backtrack while reading has always seemed an odd choice to me, exemplified by list comprehensions, especially when nested.
mixmastamyk 5y ago
It is simply a design choice, the common value is given first. Comprehensions in Py are the same.
- Zababa 5y ago
  Sure it's a design choice but, quoting the Zen of Python: > Special cases aren't special enough to break the rules. > There should be one-- and preferably only one --obvious way to do it. Both are broken by the existance of 2 if syntaxes depending on the context.
- DonHopkins 5y ago
  But when you write "condition ? first : second" or "(if condition first second)", the first common value is still given before the second uncommon value, so what's the advantage of putting the condition BETWEEN first and second, instead of BEFORE? After all, the condition has to be EVALUATED first before deciding which one to use. Infix "if" conditions just scramble up the order of evaluation from the order of program source code.
  - mixmastamyk 5y ago
    The argument is that the most common value should be first and the rest can be thought of as rare and almost ignored. I don’t always agree, but still prefer it to C syntax which I have to look up every time.

joshuamorton 5y ago

To add to the cacaphony of counterarguments to this, this can introduce nonobvious bugs when refactoring. If the condition-guarded statement is nontrivial and you remove the assignment, everything stays valid. If otoh you use a ternary or if x: y = 1 else: y = 2 If you now delete the else block or something (like the assignment from a larger else block), a linter can warn you that y is undefined. Otherwise you'd need a test to ensure correctness.