6 ms·

I don't think people are used to backwards compatibility breaks in languages. Though in some ways, that means you have a different language. In reality, Python

by zanny 12y ago

I don't think people are used to backwards compatibility breaks in languages. Though in some ways, that means you have a different language. In reality, Python 3 is to Python 2 what Ruby is to Python 2 - different. They aren't the same language, you could have named Python 3 Anaconda (just because Cobra is already taken, I know it is a prepackaged library bundle for Python already) and its function would be clearer. But you also can't tell people writing free software "no, you have to stop doing what you want, and do what I want" unless you are willing to negotiate how much that will cost you. And maybe they wouldn't do it for any price. You could get other developers to extend it on your doll as well. But the developers of Python collectively said "unicode is important enough to make a backwards incompatible leap". They are never painless. OpenGL is a great example, with how the version 3 line was rife with attempts to depreciate the fixed function legacy cruft, and even today few developers properly differentiate compatibility and core profiles. That is a major version break too. But if you don't like it, you can make your own. The fact there isn't a major popular python2 extension project trying to backport functionality unofficially that has gained traction should say what the popular consensus on python 3 is. If you need python2 libraries, use python2. There is really no shame in doing it. Even when the official project depreciates the maintenance of 2.7 someone will pick it up, because there will be for decades, at least, and probably for eternity, python 2 software running somewhere and the maintainers think keeping python 2 working is less effort than porting their stack to 3.

PythonicAlpha 12y ago
The problem is not only Unicode. If it only where for unicode, the problem would not so big. But they seemed not to bother at all about backwards compatibility at all in the first Py3 version. Later, they did try to change some things, that unnecessarily(!!) blocked adoption, but many projects already decided to ignore Py3. I guess, you don't mean what you said in the last paragraph? Was it just a joke? Unless you can replace all libraries that exist only as Python 2 version, you can not move -- you can use zero Python 3. That is a huge problem to real projects -- of course, if you only have some University (educational) - projects, all is fine and you can play around as you like. Also there is the problem, that it is not trivial to have Python2+3 on the same installation. Most Linux distros still run with Py2.
- icebraining 12y ago
  In what distros is that a problem? I have Python2+3 on Debian running fine side-by-side.
  - PythonicAlpha 12y ago
    When you have several Python programs, where does /usr/bin/python point to? I must admit, that I did not think to much about it until now, but normally there is only /usr/bin/python in the scripts. Of course, if everybody has /usr/bin/python3 inside his Python3 programs, everything could work (unless some of your apps need special environment vars like PYTHONPATH, what could make it troublesome again). But still, the standard installation of Debian (and others, as much I know) does not include Python3 by default, you at least have to add it to your installation. That is something, you must tell your customers, when you ship Python3 programs.
    - icebraining 12y ago
      Most package managers allow you to specify a dependency on Python 3, so you shouldn't even need to tell your customers. Otherwise, you can always use virtualenv and ship Python with your code. And yes, if you're targeting Debian or Debian-like systems, make a deb. It's really not that hard, especially with newer tools like fpm.
      - dTal 12y ago
        Thank you for mentioning fpm, I'd never heard of it and often wished for something like it. Commenting to bring attention to it, and so I don't forget!
    - deleted 12y ago
      [deleted]
    - JeremyBanks 12y ago
      /usr/bin/python should never point to Python 3. Because of the compatibility break, the convention (and default for the Python build scripts) is to always name the Python 3 binary python3, so there should be no conflict. It's understood that during the (very long) transition period there will be need to run both side by side. A handful of ditros have gone ahead and named it python anyway. A stated motivation has been to encourage adoption of Python 3, but practically they're just shooting themselves and their users in the foot, and ensuring incompatibility with the shebangs defined for every other OS. (I don't think there's any plan to ever switch the default binary name from python3 to python, so this incompatibility may never be resolved.)
klibertp 12y ago
> (just because Cobra is already taken, I know it is a prepackaged library bundle for Python already) Actually, the name really is taken and by programming language: http://cobra-language.com/ http://cobra-language.com/ - looked nice when I last looked. I didn't know about Cobra Toolbox, however.
- datashaman 12y ago
  OMF, I have been looking for Cobra's home page for years! I saw it a few years ago, and was quite impressed by it, bookmarked it and then forgot all about it. Then spent the next few years searching through Lambda the Ultimate, the Internet, etc to try and find it again. And now it's in front of me again, and more mature to boot! Whoot! :)
- vram22 12y ago
  Was going to reply to the parent of your comment, but since you beat me to it: >Actually, the name really is taken and by programming language: http://cobra-language.com/ http://cobra-language.com/ - looked nice when I last looked. The Cobra language does look interesting [1]. Checked it out a little a few weeks ago. I think it only runs on .NET and Mono, though. [1] It uses ideas from several languages, including Python. On the Cobra site, there are a few short comparisons between it and other languages, including Python: http://cobra-language.com/docs/python/ http://cobra-language.com/docs/python/ Also, it has a feature similar to Design By Contract like Eiffel does: http://cobra-language.com/docs/quality/ http://cobra-language.com/docs/quality/ Cobra is worth a look, and keeping eye on as it evolves, IMO.
  - klibertp 12y ago
    I especially like optional static typing and compile-time protection from nil/None very much. It's type system doesn't look very sophisticated, but since you get fully dynamic variables with no (syntactic) overhead it's not that important. requires and ensures are very nice (as are tests), especially because the only other language with real contracts (Racket) focuses on functions and is a bit lacking when it comes to contracting methods with side-effects. It generally looks quite nice for a niche language and it's nice that it seems to be maintained. It seems that there is a JVM underway, by the way. Boo was the other similar, interesting language I checked out some time ago, but it seems to be under less active development (if at all). Anyway, if Python 3 is such a problem, then maybe let's port everything over to Cobra. It has snake in the name and familiar syntax and lots of goodies; imagine how far it could get if hundreds of thousands Python users would start working with it! (Just joking, although I'm wishing Cobra (and all other new or unpopular) languages the best of luck, of course)
userbinator 12y ago
I don't think people are used to backwards compatibility breaks in languages. Nor do they like it, because most if not all developers are using these languages for a practical purpose: to get things done. Having to relearn and "fix" things which otherwise wouldn't need to be has a cost, and this is on top of what they already have to do. I personally think backwards compatibility and gradual change - evolution, not revolution - is the way to go. Outside of the software industry this is the norm; think of all the "interfaces" that we use in the physical world that have remained backwards-compatible and relatively stable over long periods of time. Software is different because it can change quickly and (by itself) easily, but just because it can doesn't mean it should, as if it is well-established, there is certainly a large number of dependencies on it too.
- phkahler 12y ago
  "I personally think backwards compatibility and gradual change - evolution, not revolution - is the way to go." I'm gonna guess that you're not new to C++. I say new because people who have been following it and picking up all the changes along the way often can't see the forest for the trees. That forest is ugly.
  - zanny 12y ago
    I'd argue C++ is doing it really well. They took their shitty awful C++03 base that made developers around the globe cry at night, and tried appending on top of that mess less terrible concepts. And now, modern C++11/14 doesn't look anything like C++03. Which is a blessing and a curse - they effectively depreciated a huge swathe of old practices for better new ones (refs over pointers, smart constructs over raw new / delete, lambdas and auto over void* function pointers, soon were going to have concepts and static if instead of preprocessor ifdefs). But that comes with a price. The price is that C++ is huge, the compilers are slow due to the complexity, and it is really analogous to per project technical debt. D exists because C++ was too slow. Walter (and Andre) saw this huge shortfall in standard C++03 and this entire class of functionality that should be there, because it doesn't have a performance overhead, but wasn't. Maybe they also saw how C# and Java were useful and popular, but they put this massive VM under them to simplify the implementation and standardization. Go exists because C++ was too big - for its purpose, of web server development, you wanted native performance with natural asynchrony and multi processing. It still doesn't have generics because it is pretty much a domain language, I think. Rust exists because C++, in the wake of C++11, is still a complicated mess of syntax. And in order to maintain backwards compatibility, C++ is terribly unsafe and every line of code can destroy your program. I think Rust is as close to the future of native languages, because it does the C++ thing - a general purpose language, where everything is deterministic and predictable because it is direct binary translation between language constructs and assembler with limited magic - and does that backwards compatibility break to fix the significant flaws. I still don't like the Rust syntax much, but it might one day grow on me. I don't think its really approachable though, I'd definitely be interested in trying a "pythonic" static typed language that emphasizes safety and productivity while maintaining the poster C++ ideology of providing reasonable abstractions that don't hide the details, but let the expert more intuitively interact with them.
belorn 12y ago
If the python developers wanted to spend the time to reimplemented bad behavior, they could have create a reverse "import from deprecated ...". It would solve most of the problem, while encouraging a switch to the new'er version by forcing every user to type in "import from deprecated" in top of their script. I just think they didn't want to do that, given the massive work and non-existent personal gain. However, any company that want to invest their money on it can since its open source.
- sitkack 12y ago
  This is a great idea!
pekk 12y ago
Ruby did it and we're not wringing our hands about how Ruby is dead. It's just that the whiners feel particularly empowered in Python, they believe they have a chance of getting Python 3 erased.
paddy_m 12y ago
To be fair Anaconda is the name of a leading python distribution focusing on scientific python. Note, I work for Continuum.

by zanny 12y ago

PythonicAlpha 12y ago

The problem is not only Unicode. If it only where for unicode, the problem would not so big. But they seemed not to bother at all about backwards compatibility at all in the first Py3 version. Later, they did try to change some things, that unnecessarily(!!) blocked adoption, but many projects already decided to ignore Py3. I guess, you don't mean what you said in the last paragraph? Was it just a joke? Unless you can replace all libraries that exist only as Python 2 version, you can not move -- you can use zero Python 3. That is a huge problem to real projects -- of course, if you only have some University (educational) - projects, all is fine and you can play around as you like. Also there is the problem, that it is not trivial to have Python2+3 on the same installation. Most Linux distros still run with Py2.

icebraining 12y ago
In what distros is that a problem? I have Python2+3 on Debian running fine side-by-side.
- PythonicAlpha 12y ago
  When you have several Python programs, where does /usr/bin/python point to? I must admit, that I did not think to much about it until now, but normally there is only /usr/bin/python in the scripts. Of course, if everybody has /usr/bin/python3 inside his Python3 programs, everything could work (unless some of your apps need special environment vars like PYTHONPATH, what could make it troublesome again). But still, the standard installation of Debian (and others, as much I know) does not include Python3 by default, you at least have to add it to your installation. That is something, you must tell your customers, when you ship Python3 programs.
  - icebraining 12y ago
    Most package managers allow you to specify a dependency on Python 3, so you shouldn't even need to tell your customers. Otherwise, you can always use virtualenv and ship Python with your code. And yes, if you're targeting Debian or Debian-like systems, make a deb. It's really not that hard, especially with newer tools like fpm.
    - dTal 12y ago
      Thank you for mentioning fpm, I'd never heard of it and often wished for something like it. Commenting to bring attention to it, and so I don't forget!
  - deleted 12y ago
    [deleted]
  - JeremyBanks 12y ago
    /usr/bin/python should never point to Python 3. Because of the compatibility break, the convention (and default for the Python build scripts) is to always name the Python 3 binary python3, so there should be no conflict. It's understood that during the (very long) transition period there will be need to run both side by side. A handful of ditros have gone ahead and named it python anyway. A stated motivation has been to encourage adoption of Python 3, but practically they're just shooting themselves and their users in the foot, and ensuring incompatibility with the shebangs defined for every other OS. (I don't think there's any plan to ever switch the default binary name from python3 to python, so this incompatibility may never be resolved.)

klibertp 12y ago

> (just because Cobra is already taken, I know it is a prepackaged library bundle for Python already) Actually, the name really is taken and by programming language: http://cobra-language.com/ http://cobra-language.com/ - looked nice when I last looked. I didn't know about Cobra Toolbox, however.

datashaman 12y ago
OMF, I have been looking for Cobra's home page for years! I saw it a few years ago, and was quite impressed by it, bookmarked it and then forgot all about it. Then spent the next few years searching through Lambda the Ultimate, the Internet, etc to try and find it again. And now it's in front of me again, and more mature to boot! Whoot! :)
vram22 12y ago
Was going to reply to the parent of your comment, but since you beat me to it: >Actually, the name really is taken and by programming language: http://cobra-language.com/ http://cobra-language.com/ - looked nice when I last looked. The Cobra language does look interesting [1]. Checked it out a little a few weeks ago. I think it only runs on .NET and Mono, though. [1] It uses ideas from several languages, including Python. On the Cobra site, there are a few short comparisons between it and other languages, including Python: http://cobra-language.com/docs/python/ http://cobra-language.com/docs/python/ Also, it has a feature similar to Design By Contract like Eiffel does: http://cobra-language.com/docs/quality/ http://cobra-language.com/docs/quality/ Cobra is worth a look, and keeping eye on as it evolves, IMO.
- klibertp 12y ago
  I especially like optional static typing and compile-time protection from nil/None very much. It's type system doesn't look very sophisticated, but since you get fully dynamic variables with no (syntactic) overhead it's not that important. requires and ensures are very nice (as are tests), especially because the only other language with real contracts (Racket) focuses on functions and is a bit lacking when it comes to contracting methods with side-effects. It generally looks quite nice for a niche language and it's nice that it seems to be maintained. It seems that there is a JVM underway, by the way. Boo was the other similar, interesting language I checked out some time ago, but it seems to be under less active development (if at all). Anyway, if Python 3 is such a problem, then maybe let's port everything over to Cobra. It has snake in the name and familiar syntax and lots of goodies; imagine how far it could get if hundreds of thousands Python users would start working with it! (Just joking, although I'm wishing Cobra (and all other new or unpopular) languages the best of luck, of course)

userbinator 12y ago

I don't think people are used to backwards compatibility breaks in languages. Nor do they like it, because most if not all developers are using these languages for a practical purpose: to get things done. Having to relearn and "fix" things which otherwise wouldn't need to be has a cost, and this is on top of what they already have to do. I personally think backwards compatibility and gradual change - evolution, not revolution - is the way to go. Outside of the software industry this is the norm; think of all the "interfaces" that we use in the physical world that have remained backwards-compatible and relatively stable over long periods of time. Software is different because it can change quickly and (by itself) easily, but just because it can doesn't mean it should, as if it is well-established, there is certainly a large number of dependencies on it too.

phkahler 12y ago
"I personally think backwards compatibility and gradual change - evolution, not revolution - is the way to go." I'm gonna guess that you're not new to C++. I say new because people who have been following it and picking up all the changes along the way often can't see the forest for the trees. That forest is ugly.
- zanny 12y ago
  I'd argue C++ is doing it really well. They took their shitty awful C++03 base that made developers around the globe cry at night, and tried appending on top of that mess less terrible concepts. And now, modern C++11/14 doesn't look anything like C++03. Which is a blessing and a curse - they effectively depreciated a huge swathe of old practices for better new ones (refs over pointers, smart constructs over raw new / delete, lambdas and auto over void* function pointers, soon were going to have concepts and static if instead of preprocessor ifdefs). But that comes with a price. The price is that C++ is huge, the compilers are slow due to the complexity, and it is really analogous to per project technical debt. D exists because C++ was too slow. Walter (and Andre) saw this huge shortfall in standard C++03 and this entire class of functionality that should be there, because it doesn't have a performance overhead, but wasn't. Maybe they also saw how C# and Java were useful and popular, but they put this massive VM under them to simplify the implementation and standardization. Go exists because C++ was too big - for its purpose, of web server development, you wanted native performance with natural asynchrony and multi processing. It still doesn't have generics because it is pretty much a domain language, I think. Rust exists because C++, in the wake of C++11, is still a complicated mess of syntax. And in order to maintain backwards compatibility, C++ is terribly unsafe and every line of code can destroy your program. I think Rust is as close to the future of native languages, because it does the C++ thing - a general purpose language, where everything is deterministic and predictable because it is direct binary translation between language constructs and assembler with limited magic - and does that backwards compatibility break to fix the significant flaws. I still don't like the Rust syntax much, but it might one day grow on me. I don't think its really approachable though, I'd definitely be interested in trying a "pythonic" static typed language that emphasizes safety and productivity while maintaining the poster C++ ideology of providing reasonable abstractions that don't hide the details, but let the expert more intuitively interact with them.

belorn 12y ago

If the python developers wanted to spend the time to reimplemented bad behavior, they could have create a reverse "import from deprecated ...". It would solve most of the problem, while encouraging a switch to the new'er version by forcing every user to type in "import from deprecated" in top of their script. I just think they didn't want to do that, given the massive work and non-existent personal gain. However, any company that want to invest their money on it can since its open source.

sitkack 12y ago
This is a great idea!

pekk 12y ago

Ruby did it and we're not wringing our hands about how Ruby is dead. It's just that the whiners feel particularly empowered in Python, they believe they have a chance of getting Python 3 erased.

paddy_m 12y ago

To be fair Anaconda is the name of a leading python distribution focusing on scientific python. Note, I work for Continuum.