6 ms·

Here’s why (Hettinger): > In 1991, “else” was the obvious choice because of the traditional way compilers implemented while-loops: pastebin.com/tY35CTJ4 That

Here’s why (Hettinger): > In 1991, “else” was the obvious choice because of the traditional way compilers implemented while-loops: pastebin.com/tY35CTJ4 That is, “if I haven’t finished the loop, GOTO the body.” He says if he had a time machine he could tell Guido in the future we’re all using structured programming so no one will find “else” intuitive; call it “nobreak” instead: https://m.youtube.com/watch?v=OSGv2VnC0go# https://m.youtube.com/watch?v=OSGv2VnC0go# Guido says if he had a time machine he would not have included the feature at all: https://mail.python.org/pipermail/python-ideas/2009-October/006157.html https://mail.python.org/pipermail/python-ideas/2009-October/... This whole thing was Knuth’s idea, not Guido’s: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.103.6084&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.103...

pmontra 8y ago
> Guido says if he had a time machine he would not have included the feature at all So deprecate it with a runtime warning and remove it after some years. I wonder if there are some statistics about its usage. I guess it's very low.
- noobermin 8y ago
  Why remove a feature that could be useful? That makes no sense. Just because it isn't named in a way people find intuitive doesn't mean it isn't useful.
  - some_account 8y ago
    Goto is also useful... See why now?
    - reificator 8y ago
      This comment contains more snark than content, but I'll reply anyway: Goto is considered harmful, but it's important to recognize the context of that decision rather than parroting the idea. It's not an obvious idea and if the discussion had happened today with modern languages[0] instead it's not at all obvious the same conclusions would be reached. This write-up does a pretty fair job of translating the original paper to something more modern without a lot of bias. http://david.tribble.com/text/goto.html http://david.tribble.com/text/goto.html [0]: Modern languages of course learned from this paper, so that's not a fair comparison. In fact golang contains a goto, but it behaves well according to Dijkstra's concerns and occasionally results in more readable code. I would be shocked if Dijkstra took any issue with go's implementation.
  - kevinavery 8y ago
    Unintuitive features that "could be useful" sounds like the antithesis of good design.
    - fileeditview 8y ago
      And it sounds like a common problem in the software industry.
  - nerdwaller 8y ago
    I find it hard to argue it’s (the else block) any more useful than just using the `else` block’s logic in the try block. try: import uvloop asyncio.set_event_loop_policy(uvloop.EventLoopPolicy) except ImportError: pass Does the handler for if the try succeeds need to be in an else, separated from the success logic?
    - figgis 8y ago
      You can actually use else for try statements. Doesn't answer question but it's something I learned relatively recently and may help some others. try: import uvloop asyncio.set_event_loop_policy(uvloop.EventLoopPolicy) except ImportError: pass else: print("well that didn't work")
      - pmontra 8y ago
        I'm not sure about what the message in that print() refers to (else fires if the import succeeded) so here's another example $ python3 >>> try: 1/0 except ZeroDivisionError: print("exception") else: print("surprise") exception >>> try: 1/1 except ZeroDivisionError: print("exception") else: print("normal") 1.0 normal The choice of the name else is unfortunate because it's activated under the same circumstances of a then branch of an "if". Maybe its name should really be "then". That would also look like a .then of a JavaScript Promise, which would make sense nowadays and was obviously impossible to foresee back in 1991. However the name "else" makes sense if it refers to "except": it's what happens when no "except" fire. I still don't understand why it should be "else" for a "for" that succeeded: it should be a "then" there.
        saurik 8y ago
        In the case of a for loop, you are modeling "a for which did not break". The cases where you want that block are typically when you are looping through a list trying to find something, so "if I found it I broke, else do this default logic".
  - jb1991 8y ago
    > Why remove a feature that could be useful? That makes no sense. It makes sense in the way that a language which is strongly biased to readability and consistent expectations makes sense. It is also how a language which minimizes programmer error makes sense. For languages that refuse to remove anything, and thus suffer from unnecessary challenges, see C++.
    - larschdk 8y ago
      Several things have been removed from C++, including auto_ptr, exception specifications, unary/binary_functions, trigraphs.
      - jlebar 8y ago
        I think the extreme difficulty and indeed controversy that the committee stared down when removing trigraphs, which are a useless feature that the vast majority of C++ programmers will never once encounter, speaks well to GP's point that C++ is very conservative in how it removes features. Maybe not JS-level careful. But still.
        anyzen 8y ago
        Of course, JS has a problem in this regard that while it looks like a language, it is also a (de facto) assembler for the browsers. So disabling anything in JS will break lots of sites which will never be fixed. However as far as programming is concerned, many things have been deprecated through transpilers and linters (for example "==" throws a warning in ESlint).
      - hellofunk 8y ago
        Most legacy cpp features and language semantics will never be removed, despite what many prominent voices in the community think.
  - coldtea 8y ago
    >Why remove a feature that could be useful? That makes no sense. Cleaning up a language "makes no sense"? Besides "could be useful" can be said for anything. Features should prove their usefulness (and in this case Guido regrets even adding it), we don't just keep them around in the off chance that they might be. That's hoarding.
    - Retra 8y ago
      You want a major version bump on very widely used software just to remove something that causes a minor confusion on the rare occasion it is used? In what world does that sound like a good idea? It's one thing to make a change like this along with a bunch of other breaking changes, but there is no way this justifies breakage by itself.
      - coldtea 8y ago
        >You want a major version bump on very widely used software just to remove something that causes a minor confusion on the rare occasion it is used? No, I want a deprecation warning, and an eventual removal when for 4.0 lands. >In what world does that sound like a good idea? In a world where we don't pile crap upon crap forever, like with POSIX, X-Windows, or C++.
        jononor 8y ago
        There are reason those systems are still widespread in use today, strong compatibility is one of them.
        coldtea 8y ago
        There are also reasons those systems have tons of accidental complexity that frustrate users and wastes endless workhours. Strong compatibility is one of them.
  - oblio 8y ago
    > Why remove a feature that could be useful? That makes no sense. Everything has a cost. In maintenance, in documentation, in support, in limiting the design space or constraining further development for other reasons (performance, for example). Nothing is truly free. Everything has to be balanced regarding costs and benefits.
  - tomtimtall 8y ago
    Because readability counts, and id at the core of Python.
  - nemoniac 8y ago
    Here's the first sentence of the spec of the Scheme programming language: "Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary."
    - goatlover 8y ago
      It's interesting how Lisp languages get criticized for lack of maintainable because of their power to let you essentially add new features, but then every popular modern language with the exception of Go piles on new features over time.
      - junke 8y ago
        Go is still relatively young.
    - kazinator 8y ago
      That grand statement is made possible by banishing needed Scheme features into numerous SRFI documents, and into implementations.
- ProblemFactory 8y ago
  > So deprecate it with a runtime warning and remove it after some years. After the Python3 brouhaha, I think people are very cautious about making backwards incompatible changes to the language, even with a deprecation warning. If it was done together with the rest of Python3 changes then it could have been approved, but not any more. As Guido suggests, adding the warning to pylint and other style checkers, but keeping compatibility is much easier.
- gvx 8y ago
  I whipped up something to test that: https://gist.github.com/gvx/667efcd263b18d313801c1b1ffa41509 https://gist.github.com/gvx/667efcd263b18d313801c1b1ffa41509 Running that on my personal projects folder gives me the following result: for elses 60 for loops 1815 # modules 598 # skipped 2
  - pmontra 8y ago
    Thanks. I run your program on a couple of projects of a customer. I'm not the only developer. for elses 0 for loops 428 # modules 673 # skipped 26 for elses 99 for loops 6058 # modules 2016 # skipped 286
- boomlinde 8y ago
  Runtime warning on what channel without breaking compatibility?
  - verandaguy_alt 8y ago
    You could print the warning out to STDERR when the Python runtime finishes parsing and before it executes your script. This will likely break some people's workflows, but honestly, it's the de-facto way of notifying users of a deprecation in many Python frameworks (Gunicorn did this recently with gunicorn-paster vs gunicorn --paste). They could also include this in a "What's new in Python (4?)" since this is unlikely to be introduced in a minor version bump.
    - boomlinde 8y ago
      I'm not categorically against deprecation warnings. Isn't gunicorn a command line tool? I can respect such warnings in a tool or even sometimes a library, but not in a language interpreter. The user should as closely as possible be in full control of the streams in those cases, and any standard error output that isn't an exception (i.e. either deliberate or resulting from a programmer error) should stay the hell off. The proper way to handle this is of course to introduce a new semver major version. No need for deprecation warnings because incompatibility is expected.
- mayankkaizen 8y ago
  Actually I wouldn't like it deprecated, not because I use it often or like it very much. In fact, I myself found this feature counterintuitive at first brush. Deprecating any feature without any strong reason makes me irritateted and I don't find any strong reason for doing so.
- karmakaze 8y ago
  The thing to do here is deprecate 'for-else' in favor of 'for-default' which is much clearer like in a case block. 'for-else' never needs to be removed but the code cleanup will happen over time.
evandijk70 8y ago
If Guido would not have included the feature at all, why did he not remove it from Python 3? That would have been the perfect opportunity.
- figgis 8y ago
  Python 3 had it's first release in 2008, that thread was from 2009. Probably didn't even really think about it before then. (the more you know)
qwerty456127 8y ago
> He says if he had a time machine he could tell Guido in the future we’re all using structured programming Sounds like if people were not already coding C, C++ and Pascal when Python was invented...

pmontra 8y ago

> Guido says if he had a time machine he would not have included the feature at all So deprecate it with a runtime warning and remove it after some years. I wonder if there are some statistics about its usage. I guess it's very low.

noobermin 8y ago
Why remove a feature that could be useful? That makes no sense. Just because it isn't named in a way people find intuitive doesn't mean it isn't useful.
- some_account 8y ago
  Goto is also useful... See why now?
  - reificator 8y ago
    This comment contains more snark than content, but I'll reply anyway: Goto is considered harmful, but it's important to recognize the context of that decision rather than parroting the idea. It's not an obvious idea and if the discussion had happened today with modern languages[0] instead it's not at all obvious the same conclusions would be reached. This write-up does a pretty fair job of translating the original paper to something more modern without a lot of bias. http://david.tribble.com/text/goto.html http://david.tribble.com/text/goto.html [0]: Modern languages of course learned from this paper, so that's not a fair comparison. In fact golang contains a goto, but it behaves well according to Dijkstra's concerns and occasionally results in more readable code. I would be shocked if Dijkstra took any issue with go's implementation.
- kevinavery 8y ago
  Unintuitive features that "could be useful" sounds like the antithesis of good design.
  - fileeditview 8y ago
    And it sounds like a common problem in the software industry.
- nerdwaller 8y ago
  I find it hard to argue it’s (the else block) any more useful than just using the `else` block’s logic in the try block. try: import uvloop asyncio.set_event_loop_policy(uvloop.EventLoopPolicy) except ImportError: pass Does the handler for if the try succeeds need to be in an else, separated from the success logic?
  - figgis 8y ago
    You can actually use else for try statements. Doesn't answer question but it's something I learned relatively recently and may help some others. try: import uvloop asyncio.set_event_loop_policy(uvloop.EventLoopPolicy) except ImportError: pass else: print("well that didn't work")
    - pmontra 8y ago
      I'm not sure about what the message in that print() refers to (else fires if the import succeeded) so here's another example $ python3 >>> try: 1/0 except ZeroDivisionError: print("exception") else: print("surprise") exception >>> try: 1/1 except ZeroDivisionError: print("exception") else: print("normal") 1.0 normal The choice of the name else is unfortunate because it's activated under the same circumstances of a then branch of an "if". Maybe its name should really be "then". That would also look like a .then of a JavaScript Promise, which would make sense nowadays and was obviously impossible to foresee back in 1991. However the name "else" makes sense if it refers to "except": it's what happens when no "except" fire. I still don't understand why it should be "else" for a "for" that succeeded: it should be a "then" there.
      - saurik 8y ago
        In the case of a for loop, you are modeling "a for which did not break". The cases where you want that block are typically when you are looping through a list trying to find something, so "if I found it I broke, else do this default logic".
- jb1991 8y ago
  > Why remove a feature that could be useful? That makes no sense. It makes sense in the way that a language which is strongly biased to readability and consistent expectations makes sense. It is also how a language which minimizes programmer error makes sense. For languages that refuse to remove anything, and thus suffer from unnecessary challenges, see C++.
  - larschdk 8y ago
    Several things have been removed from C++, including auto_ptr, exception specifications, unary/binary_functions, trigraphs.
    - jlebar 8y ago
      I think the extreme difficulty and indeed controversy that the committee stared down when removing trigraphs, which are a useless feature that the vast majority of C++ programmers will never once encounter, speaks well to GP's point that C++ is very conservative in how it removes features. Maybe not JS-level careful. But still.
      - anyzen 8y ago
        Of course, JS has a problem in this regard that while it looks like a language, it is also a (de facto) assembler for the browsers. So disabling anything in JS will break lots of sites which will never be fixed. However as far as programming is concerned, many things have been deprecated through transpilers and linters (for example "==" throws a warning in ESlint).
    - hellofunk 8y ago
      Most legacy cpp features and language semantics will never be removed, despite what many prominent voices in the community think.
- coldtea 8y ago
  >Why remove a feature that could be useful? That makes no sense. Cleaning up a language "makes no sense"? Besides "could be useful" can be said for anything. Features should prove their usefulness (and in this case Guido regrets even adding it), we don't just keep them around in the off chance that they might be. That's hoarding.
  - Retra 8y ago
    You want a major version bump on very widely used software just to remove something that causes a minor confusion on the rare occasion it is used? In what world does that sound like a good idea? It's one thing to make a change like this along with a bunch of other breaking changes, but there is no way this justifies breakage by itself.
    - coldtea 8y ago
      >You want a major version bump on very widely used software just to remove something that causes a minor confusion on the rare occasion it is used? No, I want a deprecation warning, and an eventual removal when for 4.0 lands. >In what world does that sound like a good idea? In a world where we don't pile crap upon crap forever, like with POSIX, X-Windows, or C++.
      - jononor 8y ago
        There are reason those systems are still widespread in use today, strong compatibility is one of them.
        coldtea 8y ago
        There are also reasons those systems have tons of accidental complexity that frustrate users and wastes endless workhours. Strong compatibility is one of them.
- oblio 8y ago
  > Why remove a feature that could be useful? That makes no sense. Everything has a cost. In maintenance, in documentation, in support, in limiting the design space or constraining further development for other reasons (performance, for example). Nothing is truly free. Everything has to be balanced regarding costs and benefits.
- tomtimtall 8y ago
  Because readability counts, and id at the core of Python.
- nemoniac 8y ago
  Here's the first sentence of the spec of the Scheme programming language: "Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary."
  - goatlover 8y ago
    It's interesting how Lisp languages get criticized for lack of maintainable because of their power to let you essentially add new features, but then every popular modern language with the exception of Go piles on new features over time.
    - junke 8y ago
      Go is still relatively young.
  - kazinator 8y ago
    That grand statement is made possible by banishing needed Scheme features into numerous SRFI documents, and into implementations.
ProblemFactory 8y ago
> So deprecate it with a runtime warning and remove it after some years. After the Python3 brouhaha, I think people are very cautious about making backwards incompatible changes to the language, even with a deprecation warning. If it was done together with the rest of Python3 changes then it could have been approved, but not any more. As Guido suggests, adding the warning to pylint and other style checkers, but keeping compatibility is much easier.
gvx 8y ago
I whipped up something to test that: https://gist.github.com/gvx/667efcd263b18d313801c1b1ffa41509 https://gist.github.com/gvx/667efcd263b18d313801c1b1ffa41509 Running that on my personal projects folder gives me the following result: for elses 60 for loops 1815 # modules 598 # skipped 2
- pmontra 8y ago
  Thanks. I run your program on a couple of projects of a customer. I'm not the only developer. for elses 0 for loops 428 # modules 673 # skipped 26 for elses 99 for loops 6058 # modules 2016 # skipped 286
boomlinde 8y ago
Runtime warning on what channel without breaking compatibility?
- verandaguy_alt 8y ago
  You could print the warning out to STDERR when the Python runtime finishes parsing and before it executes your script. This will likely break some people's workflows, but honestly, it's the de-facto way of notifying users of a deprecation in many Python frameworks (Gunicorn did this recently with gunicorn-paster vs gunicorn --paste). They could also include this in a "What's new in Python (4?)" since this is unlikely to be introduced in a minor version bump.
  - boomlinde 8y ago
    I'm not categorically against deprecation warnings. Isn't gunicorn a command line tool? I can respect such warnings in a tool or even sometimes a library, but not in a language interpreter. The user should as closely as possible be in full control of the streams in those cases, and any standard error output that isn't an exception (i.e. either deliberate or resulting from a programmer error) should stay the hell off. The proper way to handle this is of course to introduce a new semver major version. No need for deprecation warnings because incompatibility is expected.
mayankkaizen 8y ago
Actually I wouldn't like it deprecated, not because I use it often or like it very much. In fact, I myself found this feature counterintuitive at first brush. Deprecating any feature without any strong reason makes me irritateted and I don't find any strong reason for doing so.
karmakaze 8y ago
The thing to do here is deprecate 'for-else' in favor of 'for-default' which is much clearer like in a case block. 'for-else' never needs to be removed but the code cleanup will happen over time.

evandijk70 8y ago

If Guido would not have included the feature at all, why did he not remove it from Python 3? That would have been the perfect opportunity.

figgis 8y ago
Python 3 had it's first release in 2008, that thread was from 2009. Probably didn't even really think about it before then. (the more you know)

qwerty456127 8y ago

> He says if he had a time machine he could tell Guido in the future we’re all using structured programming Sounds like if people were not already coding C, C++ and Pascal when Python was invented...