8 ms·

Background ("PEP 572 and decision-making in Python"): https://lwn.net/Articles/757713/ https://lwn.net/Articles/757713/

by js2 8y ago

jcelerier 8y ago
> The problem with the C-style of assignments is that it leads to this classic error: if(x = 0) {...} yeah, if you code on 20 years old compilers with no warnings. GCC 4.1 warns about this (with -Wall) and Clang 3.4 warns about this too, without any warning flag.
- Waterluvian 8y ago
  I think that having strong opinions on how others should be developing software is how communities become toxic like this. "Shooting yourself in the foot is your fault for not using a linter that detects accidental misuse of assignment!"
  - jcelerier 8y ago
    > I think that having strong opinions on how others should be developing software is how communities become toxic like this. Depends on what you think the answer to "is programming an art or a science" is. People who build bridges are absolutely subject to "strong opinions" on how to build bridges. I am of the opinion that shipping software to others when under a contract without using all the facilities available to prevent problems - linting, static type checking, etc - should be considered at best a breach of contract and ideally criminal negligence.
    - Waterluvian 8y ago
      You're right. There are times where being right is absolutely imperative. Maybe it's a know it when you see it kind of thing. When the debate isn't killing people, it's potentially inconvenient extra coding by a developer, and to appreciate the immense social cost those debates can have.
    - icebraining 8y ago
      Programming languages are not just used for shipping software to others when under a contract. Specially Python, which is often used as a teaching language.
    - woah 8y ago
      Thinking that linting and static typing will stop all errors is foolish (although I prefer both, myself). Cargo culting "best practices" is often useless, and is sometimes used as a crutch by developers who are bad at the much more important and much less quantifiable things, like code readability and architectural simplicity. Wanting your pet coding preferences to be enforced by criminal law is a sadomasochistic fantasy.
      - jcelerier 8y ago
        > Thinking that linting and static typing will stop all errors is foolish (although I prefer both, myself). Thinking that putting a seatbelt will prevent death in a crash is foolish, and yet they are still mandatory
        mkesper 8y ago
        Here you are very wrong. Look at https://www.cdc.gov/motorvehiclesafety/seatbelts/facts.html#tabs-2-3 https://www.cdc.gov/motorvehiclesafety/seatbelts/facts.html#... or https://en.wikipedia.org/wiki/Seat_belt https://en.wikipedia.org/wiki/Seat_belt
        jcelerier 8y ago
        that's exactly what I mean. Seatbelts won't save you every time but they save you enough times that they are mandatory. > In another study that examined injuries presenting to the ER pre- and post-seat belt law introduction, it was found that 40% more escaped injury and 35% more escaped mild and moderate injuries.[83] I don't know how many bugs can use of all possible explicit typing and compiler warnings avert but I'd wager that it would be at least as high a percentage.
        wrmsr 8y ago
        And as a former motorcyclist the idea of putting a seatbelt on a bike is terrifying, but under the umbrella of 'mandatory' I'd have to risk getting cut in half in a fender bender 'because that's how it's done'. If you blindly follow guidelines without understanding why they were put in place and when they should be circumvented you do more harm than good. In this context specifically, a python thread, I've not even found formatters that 'just work' in python to the degree that they do in java - I get and support significant whitespace but that combined with the crazy calling convention frequently lead me to just have to suffix spans of lines with noqa because I'm communicating to the reader something that a dumb bot doesn't understand. And that's not even getting into the heavier stuff, I type annotate everything but mypy is beyond useless for my relevant codebases - it no longer just outputs walls of useless noise it straight up crashes, from the most minimal use of even descriptors much less metaclasses. Tools and policies are essential but at the end of the day humans and situations are still currently authoritative.
    - jodrellblank 8y ago
      I feel like you could have written this https://jjj.blog/2016/08/todays-software-is-terrible/ https://jjj.blog/2016/08/todays-software-is-terrible/
  - TooBrokeToBeg 8y ago
    I'm still puzzled to why would a compiler allow assignment in an explicit conditional (outside of loop syntax). It's like a baked-in blindspot that most people just want to ignore for some reason. Some languages actually guard against this well enough (eg Kotlin) and say "don't". Even with guards in place, it's not all that complicated to work around in the edge cases where you might want to do it.
    - arkadiytehgraet 8y ago
      Funny you should mention Kotlin; while I like the language a lot, I believe this particular feature would be of immense help in the following scenario: Imagine you have a sealed class Foo, with `class Bar(x: String) : Foo()` and `Baz() : Foo()`. Now, imagine you have a method, returning an object of type Foo: `fun foo(): Foo` And you want to pattern match on the result of this method: when(foo()) { is Bar -> ... is Baz -> ... } Now, the problem is: how do you access String field x in the first branch? The only way to do it now is to extract the methos call into redundant local variable, and then pattern match it instead of `foo()` directly as I did above. Now imagine Kotlin had that feature; then we could just do the following: when(foo = foo()) { is Bar -> foo.x is Baz -> ... }
      - bpicolo 8y ago
        One option is match statements. Great way to make this sort of inline assignment unnecessary
        arkadiytehgraet 8y ago
        Could you please elaborate more on what you mean by match statements? Is it an already existing feature of Kotlin?
        bpicolo 8y ago
        Ah, I guess `when` is literally Kotlin's equivalent of match. What I'm thinking of here is Rust's match statements, which do give you the ability to make use of those intermediary values by making use of Rust's enum type. https://doc.rust-lang.org/book/second-edition/ch06-02-match.html#matching-with-optiont https://doc.rust-lang.org/book/second-edition/ch06-02-match....
  - Dayshine 8y ago
    Linter? You mean compiler right? The compiler should be warning for things like this, not relying on 3rd party tools. So, yes, if you're using a custom compiler, you kinda are to blame for shooting yourself in the foot. Just use the official binaries!
    - dvlsg 8y ago
      Depends on the language. Javascript, for example, would use a linter for this warning.
    - KSteffensen 8y ago
      It's not that easy for the compiler to provide these warnings when the language is interpreted rather than compiled
      - TooBrokeToBeg 8y ago
        The compiler can do anything a linter can do. Multi-pass multithreaded compilers are not unheard of. eg While compiling to temporary storage, I do a linting in another thread. At the end, check for successes and move the artifacts into the output directory.
        TwelveNights 8y ago
        What the poster means is that a compiler may not be as applicable to interpreted languages.
- jstimpfle 8y ago
  Not having a problem in the first place is preferable to fighting it with tools. == vs = is a classic mistake that I'm sure every C programmer has wasted some time on. (I'm just undecided if I prefer dealing with this very problem occasionally, or choosing either of the verbosity of := assignments or the non-orthogonality of = assignment statements plus := assignment expressions.)
  - bluecalm 8y ago
    Well, the best option would be to have := (or any other operator) as C style assignment in the first place. This is huge backward compatibility breakage though so the second best option is to use =. You can require additional brackets around assignment if you use the returning value (or otherwise it's syntax error). They did that with the new one anyway.
    - thomasahle 8y ago
      > You can require additional brackets around assignment if you use the returning value (or otherwise it's syntax error). They did that with the new one anyway. They only did it if the := is at the root level. The following is completely legal: if match := re.search(pat, text): `print("Found:", match.group(0)) or [y := f(x), y**2, y**3]
      - bluecalm 8y ago
        Great, I haven't used := thing yet. I think it's more elegant like that.
  - sbjs 8y ago
    A programming language and the tools you use with it are tightly integrated: you're never using a language, you're always using a language via a tool. And if all C compilers you might use have warnings enabled for this buggy expression, then there's no problem.
    - orf 8y ago
- iainmerrick 8y ago
  What do you do if you really do intend the assignment? (Assume for the sake of argument it’s some more reasonable example like "if (x = re_match(foo, bar)) {...}")
  - 613style 8y ago
    You wrap it in parens to avoid the warning: if ((x = 7)) { ... }
  - Tyr42 8y ago
    You do "if (((x = re_match(foo, bar))) {...}". At least the systems I've seen need a extra (()) around = to disable the warnings and notify the reader that you're not just comparing for equality.
  - thestoicattack 8y ago
    C++17 has if-statement initializers, so you can do if (auto x = re_match(foo, bar); x.has_value()) { (or x.ok() or whatever the name is of the method that tells you the validity of x)
- raverbashing 8y ago
  Warnings in Python are very rare, and only for good reasons Throwing warnings for "common code" would be uncharacteristic.
bluecalm 8y ago
Well, when he is dealing with arguments as silly as "but we will confuse = with ==) it's not a surprise he is tired and had enough. I just wish he had pushed through C style assignment before retiring. New syntax is ugly and introduces a new operator which basically does the same thing. When I've seen this PEP for the first time I thought he lost his touch after so many fantastic design decisions throughout the years. Now I realize he just had enough. Thanks Guido for fantastic language. I wouldn't find love for programming if it wasn't for you.
- Tehnix 8y ago
  > Well, when he is dealing with arguments as silly as "but we will confuse = with ==)... You clearly never had exposure to a PHP codebase. If people can trip up, people will trip up.
- joshuamorton 8y ago
  Guido (along with most core devs) are actively against c-style assignment. This pep was a compromise that Guido felt was good. But c-style assignment in Python was never going to happen, not should it have.
- sevensor 8y ago
  My reaction was the opposite -- I didn't know about PEP572, read it immediately after this retirement announcement. My response was, "where has this feature been all these years?" I'm delighted by the addition -- it removes a lot of "loop and a half" ugliness without adding do loops, it simplifies list comprehensions, it lets you remove opportunities to make mistakes, and it doesn't let you put a single-equals assignment inside a conditional as a typo.
  - sneakermoney 8y ago
    Same here, I often find myself writing a loop-and-a-half and will on occasion repeat expressions to get around extra lines (if I cared about performance, I wouldn't be writing it in Python). I feel like a lot of the resistance is from people who think this is somehow bad style, because it's associated with a source of bugs in other languages. The same kind of people will argue endlessly against having 'goto' in a language, even when it can clearly make for cleaner code (eat it, Dijkstra!) in some cases.

Background ("PEP 572 and decision-making in Python"): https://lwn.net/Articles/757713/ https://lwn.net/Articles/757713/

by js2 8y ago

Background ("PEP 572 and decision-making in Python"): https://lwn.net/Articles/757713/ https://lwn.net/Articles/757713/

> The problem with the C-style of assignments is that it leads to this classic error: if(x = 0) {...} yeah, if you code on 20 years old compilers with no warnings. GCC 4.1 warns about this (with -Wall) and Clang 3.4 warns about this too, without any warning flag.

Waterluvian 8y ago
I think that having strong opinions on how others should be developing software is how communities become toxic like this. "Shooting yourself in the foot is your fault for not using a linter that detects accidental misuse of assignment!"
- jcelerier 8y ago
  > I think that having strong opinions on how others should be developing software is how communities become toxic like this. Depends on what you think the answer to "is programming an art or a science" is. People who build bridges are absolutely subject to "strong opinions" on how to build bridges. I am of the opinion that shipping software to others when under a contract without using all the facilities available to prevent problems - linting, static type checking, etc - should be considered at best a breach of contract and ideally criminal negligence.
  - Waterluvian 8y ago
    You're right. There are times where being right is absolutely imperative. Maybe it's a know it when you see it kind of thing. When the debate isn't killing people, it's potentially inconvenient extra coding by a developer, and to appreciate the immense social cost those debates can have.
  - icebraining 8y ago
    Programming languages are not just used for shipping software to others when under a contract. Specially Python, which is often used as a teaching language.
  - woah 8y ago
    Thinking that linting and static typing will stop all errors is foolish (although I prefer both, myself). Cargo culting "best practices" is often useless, and is sometimes used as a crutch by developers who are bad at the much more important and much less quantifiable things, like code readability and architectural simplicity. Wanting your pet coding preferences to be enforced by criminal law is a sadomasochistic fantasy.
    - jcelerier 8y ago
      > Thinking that linting and static typing will stop all errors is foolish (although I prefer both, myself). Thinking that putting a seatbelt will prevent death in a crash is foolish, and yet they are still mandatory
      - mkesper 8y ago
        Here you are very wrong. Look at https://www.cdc.gov/motorvehiclesafety/seatbelts/facts.html#tabs-2-3 https://www.cdc.gov/motorvehiclesafety/seatbelts/facts.html#... or https://en.wikipedia.org/wiki/Seat_belt https://en.wikipedia.org/wiki/Seat_belt
        jcelerier 8y ago
        that's exactly what I mean. Seatbelts won't save you every time but they save you enough times that they are mandatory. > In another study that examined injuries presenting to the ER pre- and post-seat belt law introduction, it was found that 40% more escaped injury and 35% more escaped mild and moderate injuries.[83] I don't know how many bugs can use of all possible explicit typing and compiler warnings avert but I'd wager that it would be at least as high a percentage.
        wrmsr 8y ago
        And as a former motorcyclist the idea of putting a seatbelt on a bike is terrifying, but under the umbrella of 'mandatory' I'd have to risk getting cut in half in a fender bender 'because that's how it's done'. If you blindly follow guidelines without understanding why they were put in place and when they should be circumvented you do more harm than good. In this context specifically, a python thread, I've not even found formatters that 'just work' in python to the degree that they do in java - I get and support significant whitespace but that combined with the crazy calling convention frequently lead me to just have to suffix spans of lines with noqa because I'm communicating to the reader something that a dumb bot doesn't understand. And that's not even getting into the heavier stuff, I type annotate everything but mypy is beyond useless for my relevant codebases - it no longer just outputs walls of useless noise it straight up crashes, from the most minimal use of even descriptors much less metaclasses. Tools and policies are essential but at the end of the day humans and situations are still currently authoritative.
  - jodrellblank 8y ago
    I feel like you could have written this https://jjj.blog/2016/08/todays-software-is-terrible/ https://jjj.blog/2016/08/todays-software-is-terrible/
- TooBrokeToBeg 8y ago
  I'm still puzzled to why would a compiler allow assignment in an explicit conditional (outside of loop syntax). It's like a baked-in blindspot that most people just want to ignore for some reason. Some languages actually guard against this well enough (eg Kotlin) and say "don't". Even with guards in place, it's not all that complicated to work around in the edge cases where you might want to do it.
  - arkadiytehgraet 8y ago
    Funny you should mention Kotlin; while I like the language a lot, I believe this particular feature would be of immense help in the following scenario: Imagine you have a sealed class Foo, with `class Bar(x: String) : Foo()` and `Baz() : Foo()`. Now, imagine you have a method, returning an object of type Foo: `fun foo(): Foo` And you want to pattern match on the result of this method: when(foo()) { is Bar -> ... is Baz -> ... } Now, the problem is: how do you access String field x in the first branch? The only way to do it now is to extract the methos call into redundant local variable, and then pattern match it instead of `foo()` directly as I did above. Now imagine Kotlin had that feature; then we could just do the following: when(foo = foo()) { is Bar -> foo.x is Baz -> ... }
    - bpicolo 8y ago
      One option is match statements. Great way to make this sort of inline assignment unnecessary
      - arkadiytehgraet 8y ago
        Could you please elaborate more on what you mean by match statements? Is it an already existing feature of Kotlin?
        bpicolo 8y ago
        Ah, I guess `when` is literally Kotlin's equivalent of match. What I'm thinking of here is Rust's match statements, which do give you the ability to make use of those intermediary values by making use of Rust's enum type. https://doc.rust-lang.org/book/second-edition/ch06-02-match.html#matching-with-optiont https://doc.rust-lang.org/book/second-edition/ch06-02-match....
- Dayshine 8y ago
  Linter? You mean compiler right? The compiler should be warning for things like this, not relying on 3rd party tools. So, yes, if you're using a custom compiler, you kinda are to blame for shooting yourself in the foot. Just use the official binaries!
  - dvlsg 8y ago
    Depends on the language. Javascript, for example, would use a linter for this warning.
  - KSteffensen 8y ago
    It's not that easy for the compiler to provide these warnings when the language is interpreted rather than compiled
    - TooBrokeToBeg 8y ago
      The compiler can do anything a linter can do. Multi-pass multithreaded compilers are not unheard of. eg While compiling to temporary storage, I do a linting in another thread. At the end, check for successes and move the artifacts into the output directory.
      - TwelveNights 8y ago
        What the poster means is that a compiler may not be as applicable to interpreted languages.
jstimpfle 8y ago
Not having a problem in the first place is preferable to fighting it with tools. == vs = is a classic mistake that I'm sure every C programmer has wasted some time on. (I'm just undecided if I prefer dealing with this very problem occasionally, or choosing either of the verbosity of := assignments or the non-orthogonality of = assignment statements plus := assignment expressions.)
- bluecalm 8y ago
  Well, the best option would be to have := (or any other operator) as C style assignment in the first place. This is huge backward compatibility breakage though so the second best option is to use =. You can require additional brackets around assignment if you use the returning value (or otherwise it's syntax error). They did that with the new one anyway.
  - thomasahle 8y ago
    > You can require additional brackets around assignment if you use the returning value (or otherwise it's syntax error). They did that with the new one anyway. They only did it if the := is at the root level. The following is completely legal: if match := re.search(pat, text): `print("Found:", match.group(0)) or [y := f(x), y**2, y**3]
    - bluecalm 8y ago
      Great, I haven't used := thing yet. I think it's more elegant like that.
- sbjs 8y ago
  A programming language and the tools you use with it are tightly integrated: you're never using a language, you're always using a language via a tool. And if all C compilers you might use have warnings enabled for this buggy expression, then there's no problem.
  - orf 8y ago
iainmerrick 8y ago
What do you do if you really do intend the assignment? (Assume for the sake of argument it’s some more reasonable example like "if (x = re_match(foo, bar)) {...}")
- 613style 8y ago
  You wrap it in parens to avoid the warning: if ((x = 7)) { ... }
- Tyr42 8y ago
  You do "if (((x = re_match(foo, bar))) {...}". At least the systems I've seen need a extra (()) around = to disable the warnings and notify the reader that you're not just comparing for equality.
- thestoicattack 8y ago
  C++17 has if-statement initializers, so you can do if (auto x = re_match(foo, bar); x.has_value()) { (or x.ok() or whatever the name is of the method that tells you the validity of x)
raverbashing 8y ago
Warnings in Python are very rare, and only for good reasons Throwing warnings for "common code" would be uncharacteristic.

bluecalm 8y ago

Well, when he is dealing with arguments as silly as "but we will confuse = with ==) it's not a surprise he is tired and had enough. I just wish he had pushed through C style assignment before retiring. New syntax is ugly and introduces a new operator which basically does the same thing. When I've seen this PEP for the first time I thought he lost his touch after so many fantastic design decisions throughout the years. Now I realize he just had enough. Thanks Guido for fantastic language. I wouldn't find love for programming if it wasn't for you.

Tehnix 8y ago
> Well, when he is dealing with arguments as silly as "but we will confuse = with ==)... You clearly never had exposure to a PHP codebase. If people can trip up, people will trip up.
joshuamorton 8y ago
Guido (along with most core devs) are actively against c-style assignment. This pep was a compromise that Guido felt was good. But c-style assignment in Python was never going to happen, not should it have.
sevensor 8y ago
My reaction was the opposite -- I didn't know about PEP572, read it immediately after this retirement announcement. My response was, "where has this feature been all these years?" I'm delighted by the addition -- it removes a lot of "loop and a half" ugliness without adding do loops, it simplifies list comprehensions, it lets you remove opportunities to make mistakes, and it doesn't let you put a single-equals assignment inside a conditional as a typo.
- sneakermoney 8y ago
  Same here, I often find myself writing a loop-and-a-half and will on occasion repeat expressions to get around extra lines (if I cared about performance, I wouldn't be writing it in Python). I feel like a lot of the resistance is from people who think this is somehow bad style, because it's associated with a source of bugs in other languages. The same kind of people will argue endlessly against having 'goto' in a language, even when it can clearly make for cleaner code (eat it, Dijkstra!) in some cases.