3 ms·

The biggest problem with the python 3 rollout was the decisions that were made to arbitrarily deprecate functionality that could have easily been supported. Ju

The biggest problem with the python 3 rollout was the decisions that were made to arbitrarily deprecate functionality that could have easily been supported. Just because you add a new way to do something doesn't mean you have to get rid of the old way, too. Another big mistake that they made was not providing any tooling to automatically convert python2 to python3 code.

dragonwriter 8y ago
> Just because you add a new way to do something doesn't mean you have to get rid of the old way, too. It kind of does if a central part of the stated philosophy of your language is “There should be one—and preferably only one—obvious way to do it.” [0] And, sure, you may say backwards compatibility creates a special circumstance that is an exception, but “Special cases aren’t special enough to break the rules.” [0] [0] PEP 20, The Zen of Python, https://www.python.org/dev/peps/pep-0020/ https://www.python.org/dev/peps/pep-0020/
- eesmith 8y ago
  Just how many ways does Python have to format a string? I can think of at least four: fmt % args, fmt.format(args), string.Template, and f"fmt". Just how many ways are there to make a string constant? single and double quotes, 'single quoted' and """triple quoted""", r"aw" and u"nicode". Probably more. That does feel like sometimes it's okay to support the old way too.
  - joshuamorton 8y ago
    >Just how many ways are there to make a string constant? single and double quotes, 'single quoted' and """triple quoted""", r"aw" and u"nicode". Probably more. Those all have different semantics. They aren't the same thing. In python 3, `''` is a unicode string. `b''` is a byte-string, `''''''` is a multiline unicode string, and `r''` is a string where backslashes are handled specially (which is useful for storing regexes and escape sequences in a human readable way). Each of those is the obvious way to do the thing. Note that the rule isn't "one way to do things" but "one obvious way". Its possible to generate a multiline string by joining a bunch of lines with `\n`, but its more obvious to use the enter key. >I can think of at least four: fmt % args, fmt.format(args), string.Template, and f"fmt". Indeed, and most would argue that % formatting should be deprecated (and would have been, if the stdlib logging module didn't rely deeply on it). Format strings and f strings, are approximately equivalent, but strings.Template objects serve a different purpose.
    - eesmith 8y ago
      What is the obvious way to write a string constant which does not contain a newline, single quote, or double quote? Should I write it: "this way" or 'this way'? PEP 8 explicitly says there is no preference. Sure, they have different semantics. But the Zen of Python suggestion isn't usually interpreted to accept, say, a 99% overlap in functionality.
      - joshuamorton 8y ago
        You didn't mention `''` vs `""`. Those have the exact same semantics. And indeed there is no preference. The zen isn't a 100% unbreakable set of rules, its guidelines though, so I'm not sure what you're trying to get out of catching Python violating a document that contains the lines > Special cases aren't special enough to break the rules. > Although practicality beats purity. The entire zen is self-contradictory, and people are well aware that python breaks the "rules" in some places. That doesn't make the guidelines bad, nor does it make the fact that they guide most of the language and its design less true. Having 2 ways of defining string constants is useful. And given that practicality beats purity and all, its acceptable to violate the Zen when its sufficiently useful.
        eesmith 8y ago
        My point is that dragonwriter's interpretation of the Zen of Python is not a strong argument against backwards compatibility support. Your comments support my argument, but you seem to have misread them as an indictment of how Python does things. Here's the thread: t0mbstone: shouldn't "arbitrarily deprecate functionality that could have easily been supported" dragonwriter: They should be because of the Zen of Python. eesmith (me): but Python does support old functionality, so don't place much weight in how to interpret the Zen of Python as it applies to (C)Python development. I did not say exactly that because I thought the inference was easy to make given the g'parent threads.
        joshuamorton 8y ago
        Ah, but here's the disagreement: > but Python does support old functionality is completely compatible with "should deprecate functionality that could have easily been supported". There should be only one way to do it is correct. Under the zen, you should bias towards deprecation. That doesn't mean deprecate every old functionality always. Indeed if there are compelling reasons not to deprecate something (the maintenance cost truly is zero, it is infeasible, the new functionality only covers a subset of uses, etc.) you shouldn't! The python mailing list and peps have a good bit of discussion about most backwards incompatible changes from py2 -> 3 (and more recent ones, like adding new keywords).
eesmith 8y ago
"could have easily been supported" While true in the abstract, who will do that support? Python core developers are stretched enough as it is. Why should they volunteer for that? "not providing any tooling to automatically convert python2 to python3 code" They did - https://docs.python.org/2/library/2to3.html https://docs.python.org/2/library/2to3.html ("2to3 is a Python program that reads Python 2.x source code and applies a series of fixers to transform it into valid Python 3.x code"). In practice that turned out to not be approach that most people wanted to do, but you can't say they provided no tooling.

dragonwriter 8y ago

> Just because you add a new way to do something doesn't mean you have to get rid of the old way, too. It kind of does if a central part of the stated philosophy of your language is “There should be one—and preferably only one—obvious way to do it.” [0] And, sure, you may say backwards compatibility creates a special circumstance that is an exception, but “Special cases aren’t special enough to break the rules.” [0] [0] PEP 20, The Zen of Python, https://www.python.org/dev/peps/pep-0020/ https://www.python.org/dev/peps/pep-0020/

eesmith 8y ago
Just how many ways does Python have to format a string? I can think of at least four: fmt % args, fmt.format(args), string.Template, and f"fmt". Just how many ways are there to make a string constant? single and double quotes, 'single quoted' and """triple quoted""", r"aw" and u"nicode". Probably more. That does feel like sometimes it's okay to support the old way too.
- joshuamorton 8y ago
  >Just how many ways are there to make a string constant? single and double quotes, 'single quoted' and """triple quoted""", r"aw" and u"nicode". Probably more. Those all have different semantics. They aren't the same thing. In python 3, `''` is a unicode string. `b''` is a byte-string, `''''''` is a multiline unicode string, and `r''` is a string where backslashes are handled specially (which is useful for storing regexes and escape sequences in a human readable way). Each of those is the obvious way to do the thing. Note that the rule isn't "one way to do things" but "one obvious way". Its possible to generate a multiline string by joining a bunch of lines with `\n`, but its more obvious to use the enter key. >I can think of at least four: fmt % args, fmt.format(args), string.Template, and f"fmt". Indeed, and most would argue that % formatting should be deprecated (and would have been, if the stdlib logging module didn't rely deeply on it). Format strings and f strings, are approximately equivalent, but strings.Template objects serve a different purpose.
  - eesmith 8y ago
    What is the obvious way to write a string constant which does not contain a newline, single quote, or double quote? Should I write it: "this way" or 'this way'? PEP 8 explicitly says there is no preference. Sure, they have different semantics. But the Zen of Python suggestion isn't usually interpreted to accept, say, a 99% overlap in functionality.
    - joshuamorton 8y ago
      You didn't mention `''` vs `""`. Those have the exact same semantics. And indeed there is no preference. The zen isn't a 100% unbreakable set of rules, its guidelines though, so I'm not sure what you're trying to get out of catching Python violating a document that contains the lines > Special cases aren't special enough to break the rules. > Although practicality beats purity. The entire zen is self-contradictory, and people are well aware that python breaks the "rules" in some places. That doesn't make the guidelines bad, nor does it make the fact that they guide most of the language and its design less true. Having 2 ways of defining string constants is useful. And given that practicality beats purity and all, its acceptable to violate the Zen when its sufficiently useful.
      - eesmith 8y ago
        My point is that dragonwriter's interpretation of the Zen of Python is not a strong argument against backwards compatibility support. Your comments support my argument, but you seem to have misread them as an indictment of how Python does things. Here's the thread: t0mbstone: shouldn't "arbitrarily deprecate functionality that could have easily been supported" dragonwriter: They should be because of the Zen of Python. eesmith (me): but Python does support old functionality, so don't place much weight in how to interpret the Zen of Python as it applies to (C)Python development. I did not say exactly that because I thought the inference was easy to make given the g'parent threads.
        joshuamorton 8y ago
        Ah, but here's the disagreement: > but Python does support old functionality is completely compatible with "should deprecate functionality that could have easily been supported". There should be only one way to do it is correct. Under the zen, you should bias towards deprecation. That doesn't mean deprecate every old functionality always. Indeed if there are compelling reasons not to deprecate something (the maintenance cost truly is zero, it is infeasible, the new functionality only covers a subset of uses, etc.) you shouldn't! The python mailing list and peps have a good bit of discussion about most backwards incompatible changes from py2 -> 3 (and more recent ones, like adding new keywords).

eesmith 8y ago

"could have easily been supported" While true in the abstract, who will do that support? Python core developers are stretched enough as it is. Why should they volunteer for that? "not providing any tooling to automatically convert python2 to python3 code" They did - https://docs.python.org/2/library/2to3.html https://docs.python.org/2/library/2to3.html ("2to3 is a Python program that reads Python 2.x source code and applies a series of fixers to transform it into valid Python 3.x code"). In practice that turned out to not be approach that most people wanted to do, but you can't say they provided no tooling.