5 ms·

You didn't hear much from the people using Python 2 to get things done. Here is what happened in that world: * there were no syntax changes, no new keywords,

You didn't hear much from the people using Python 2 to get things done. Here is what happened in that world: * there were no syntax changes, no new keywords, no deprecations, no coloured functions (http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...), no major changes in the standard library etc * some sore points (eg subprocess & threads) had backported modules with fixes * python 2.7 continued to be supported by major third party libraries, and they tended to avoid wholesale changes * binary compatibility and testing are easy (I have a python binary module compiled on 32 bit ARM in 2014 that still loads without recompilation today) ie python 2 is more than sufficient to solve real world problems, and in the last decade has been stable, debugged, and predictable. You generally don't hear from folks doing this! Much like C++, Python 3 still has the problem of which subset of language features to use since they affect minimum Python 3.x version, interaction with libraries etc. The Python 2 -> 3 transition is going to be a case study for a long time. All the intentions and planning seemed right, yet here we are a decade later. There are difficult trade offs between new productivity, stability and predictability, and giving things time to mature, with space to make mistakes. As an example Rust seems to be applying the lessons learned.

throwaway12iii 8y ago
What is wrong with LTS releases? That's what python 2.7 is.
orf 8y ago
> * binary compatibility and testing are easy (I have a python binary module compiled on 32 bit ARM in 2014 that still loads without recompilation today) I'm confused, are you trying to say a module compiled for Python 2.7 still works with Python 2.7?
- rogerbinns 8y ago
  I am saying exactly that. Note that it still works across compiler upgrades, libc updates, OS upgrades, python itself updates etc. By contrast if you compile a module against Python 3.4, it won't even work the same day against Python 3.5. ie the ever changing Python 3.x is more busy work than Python 2.7.
  - orf 8y ago
    > I am saying exactly that. Note that it still works across compiler upgrades, libc updates, OS upgrades, python itself updates etc. Of course it does. Just like every other version? Compile something for Python X and it will continue working for Python X, where X is 2.7, 3.1, 3.4, etc etc. Overall your point seems to be very confused: Modules compiled for a Python version that has had no updates in 15 years still work, and this is somehow relevant to modules working across Python releases? You're comparing apples to oranges here I feel. > By contrast if you compile a module against Python 3.4, it won't even work the same day against Python 3.5. ie the ever changing Python 3.x is more busy work than Python 2.7. Sure, that's a different thing. That's across Python versions. As a counterpoint, Tensorflow built for Python 3.6 before 3.7 even began development runs just fine on 3.7. Of course the C-API evolves, and you'll have to adapt your C-API modules. As an example 3.6 made some changes[1]. 1. https://docs.python.org/3/whatsnew/3.6.html#build-and-c-api-changes https://docs.python.org/3/whatsnew/3.6.html#build-and-c-api-...
gammateam 8y ago
I get it This isnt really about rationalizing Python2 Its about different branches of a programming language bearing sequential names Thats the only real UX problem here Naming candidates: Python++, Python Vision, Python Classic/Python, Python Core
- WorldMaker 8y ago
  How would that do anything but make it worse? If you want a real world example, how about VB6 versus VB7 and its rebrand as VB.NET (though still called VB7 by its team, and the version numbers remain sequential from there). People will fight that language war for the rest of their lives.
t0mbstone 8y ago
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.

throwaway12iii 8y ago

What is wrong with LTS releases? That's what python 2.7 is.

orf 8y ago

> * binary compatibility and testing are easy (I have a python binary module compiled on 32 bit ARM in 2014 that still loads without recompilation today) I'm confused, are you trying to say a module compiled for Python 2.7 still works with Python 2.7?

rogerbinns 8y ago
I am saying exactly that. Note that it still works across compiler upgrades, libc updates, OS upgrades, python itself updates etc. By contrast if you compile a module against Python 3.4, it won't even work the same day against Python 3.5. ie the ever changing Python 3.x is more busy work than Python 2.7.
- orf 8y ago
  > I am saying exactly that. Note that it still works across compiler upgrades, libc updates, OS upgrades, python itself updates etc. Of course it does. Just like every other version? Compile something for Python X and it will continue working for Python X, where X is 2.7, 3.1, 3.4, etc etc. Overall your point seems to be very confused: Modules compiled for a Python version that has had no updates in 15 years still work, and this is somehow relevant to modules working across Python releases? You're comparing apples to oranges here I feel. > By contrast if you compile a module against Python 3.4, it won't even work the same day against Python 3.5. ie the ever changing Python 3.x is more busy work than Python 2.7. Sure, that's a different thing. That's across Python versions. As a counterpoint, Tensorflow built for Python 3.6 before 3.7 even began development runs just fine on 3.7. Of course the C-API evolves, and you'll have to adapt your C-API modules. As an example 3.6 made some changes[1]. 1. https://docs.python.org/3/whatsnew/3.6.html#build-and-c-api-changes https://docs.python.org/3/whatsnew/3.6.html#build-and-c-api-...

gammateam 8y ago

I get it This isnt really about rationalizing Python2 Its about different branches of a programming language bearing sequential names Thats the only real UX problem here Naming candidates: Python++, Python Vision, Python Classic/Python, Python Core

WorldMaker 8y ago
How would that do anything but make it worse? If you want a real world example, how about VB6 versus VB7 and its rebrand as VB.NET (though still called VB7 by its team, and the version numbers remain sequential from there). People will fight that language war for the rest of their lives.

t0mbstone 8y ago

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.