5 ms·

Back when python 3 was introduced and after learning of breaking backward compatibility my first thought was, "good luck with that"... Wanting to create someth

by placebo 10y ago

Back when python 3 was introduced and after learning of breaking backward compatibility my first thought was, "good luck with that"... Wanting to create something better is not surprising. What was surprising (to me at least) is not seeing that people don't like change unless they see a really dramatic benefit to what they already have, and clearly see that the advantages to making that change far outweigh the discomfort of the process. Most people have a really hard time changing from something they know, even if it's less than perfect. Actually, even if it sucks. Ask any marketer, salesman, social worker or psychologist and you will see this is not limited to programming languages, and beyond the psychology, change has an economic price that needs to be justified. So, years later, the only thing I'm surprised at is that Python 3 actually caught on to the extent it did. I don't know whether to attribute this more to the quality of the language or the energy that went into promoting migration to it, but its current adoption rate to me is a mark of success when one tries to compare it with other attempts to reeducate a well established market.

hueving 10y ago
Yes, the biggest hindrance to python3 is the fact that python2 is a good language. It's very rare to come across a case where you can tell someone, "if you were using python3, this would be so much easier/more performant." Most of the migrations I have seen have been because of a stick rather than a carrot (e.g. this library we depend on is dropping py2 support). It's definitely the case that the move has only been as successful as it has because of the (relatively) unified effort of popular open source library authors to switch common dependencies.
- sametmax 10y ago
  Well, another issue is that there are carrots, but they are tough to sell. I have been using Python 3 for 2 years now in production, and I would never want to go back to Python 2. Benefits include: - less boilerplate. Automatic super(), no object inheritance, yield from, generalized unpacking, keyword only args, less itertools import, no need for __future__, f-srings, etc. Basically my code is shorter and faster to write. - better error handling. This one is big. It is easier to get a bug free Python 3 program. You get exception nesting handling, finer file exception granularity, more safety nets (e.g: no more arbitrary object comparison), better error messages, absolute import by default, regular division by default, etc. As a trainer, Python 3 is so easier to teach. - unicode is no just about u''. You have the "encoding" parameter everywhere by default. Everything default to "utf8" naturally. You don't need the # coding: monbo jumbo. There is no more "auto-casting" of bytes. English native speakers underestimate the value of this. As a European, it's invaluable to me, and it is to the rest of the world that is not using ASCII as their main alphabet. Those are really, really great benefits. But terrible carrots. They don't sell. People want big shinny stickers with "+30% perf" which will never be of used for most projects. While those benefits, I guaranty, are stuff all project benefits from, and you feel them a lot once you get used to them.
  - hueving 10y ago
    Good points, but error handling and less boilerplate are mostly moot once the code is already written, which is what makes them not great carrots for switching projects.
    - sametmax 10y ago
      Yes it's more "invest now, get the next iterations of your project in a better shape". And it's not as appealing as "invest now, get 30% speed up now".
ProblemFactory 10y ago
> So, years later, the only thing I'm surprised at is that Python 3 actually caught on to the extent it did. Well, it's been over 8 years. And we've just reached the point where nearly all libraries are available in Python3, and Python3 is recommended for starting new projects. Python3 was also a very unconventional backwards incompatible change. 90% of the incompatibility came from "you must correctly and carefully handle unicode vs bytes". All other backwards incompatible changes were trivial in comparison, almost fixable by search and replace. And "careful handling of unicode vs bytes" was something that you already could do in Python2, and should do in Python2, but weren't forced to. If you did, then upgrade to Python3 was easy. If not, then you had a massive testing and refactoring problem on your hands. I would not even see it as a language change, but would compare it to C and C++ compilers turning -Wall -Werror on as mandatory flags in the latest release. It would be sort of "good for the ecosystem" in the long term, but would also be a lot of effort for people with legacy codebases.
- saurik 10y ago
  The fact that you could choose to be that careful with Unicode in Python 2.7, though, is important to not forget: if the only change was that now you had to be, then code could have easily migrated and worked on both. This was the story of Ruby 1.9, which was, compared to Python 3, a cakewalk. The reality here is that you are just wrong in both understanding and premise :/. First, all these minor changes are actually extremely serious, as they made it hard to impossible to have cose which ran on both; as someone who was nowhere near an expert in Ruby, it was still easy to write code which straddled the boundary between 1.8 and 1.9. Ruby 1.9 really could be seen as a set of "warnings" on 1.8. Second, the most serious change in Python 3 was not Unicode, it was actually the way it handled generators and iterators and lists in various contexts: this was a set of changes which broke lots of code in subtle ways and which could not be handled using your argument of search and replace (and which contributed to the awkwardness of having code running on both 2 and 3 at the same time).

by placebo 10y ago

hueving 10y ago

Yes, the biggest hindrance to python3 is the fact that python2 is a good language. It's very rare to come across a case where you can tell someone, "if you were using python3, this would be so much easier/more performant." Most of the migrations I have seen have been because of a stick rather than a carrot (e.g. this library we depend on is dropping py2 support). It's definitely the case that the move has only been as successful as it has because of the (relatively) unified effort of popular open source library authors to switch common dependencies.

sametmax 10y ago
Well, another issue is that there are carrots, but they are tough to sell. I have been using Python 3 for 2 years now in production, and I would never want to go back to Python 2. Benefits include: - less boilerplate. Automatic super(), no object inheritance, yield from, generalized unpacking, keyword only args, less itertools import, no need for __future__, f-srings, etc. Basically my code is shorter and faster to write. - better error handling. This one is big. It is easier to get a bug free Python 3 program. You get exception nesting handling, finer file exception granularity, more safety nets (e.g: no more arbitrary object comparison), better error messages, absolute import by default, regular division by default, etc. As a trainer, Python 3 is so easier to teach. - unicode is no just about u''. You have the "encoding" parameter everywhere by default. Everything default to "utf8" naturally. You don't need the # coding: monbo jumbo. There is no more "auto-casting" of bytes. English native speakers underestimate the value of this. As a European, it's invaluable to me, and it is to the rest of the world that is not using ASCII as their main alphabet. Those are really, really great benefits. But terrible carrots. They don't sell. People want big shinny stickers with "+30% perf" which will never be of used for most projects. While those benefits, I guaranty, are stuff all project benefits from, and you feel them a lot once you get used to them.
- hueving 10y ago
  Good points, but error handling and less boilerplate are mostly moot once the code is already written, which is what makes them not great carrots for switching projects.
  - sametmax 10y ago
    Yes it's more "invest now, get the next iterations of your project in a better shape". And it's not as appealing as "invest now, get 30% speed up now".

ProblemFactory 10y ago

> So, years later, the only thing I'm surprised at is that Python 3 actually caught on to the extent it did. Well, it's been over 8 years. And we've just reached the point where nearly all libraries are available in Python3, and Python3 is recommended for starting new projects. Python3 was also a very unconventional backwards incompatible change. 90% of the incompatibility came from "you must correctly and carefully handle unicode vs bytes". All other backwards incompatible changes were trivial in comparison, almost fixable by search and replace. And "careful handling of unicode vs bytes" was something that you already could do in Python2, and should do in Python2, but weren't forced to. If you did, then upgrade to Python3 was easy. If not, then you had a massive testing and refactoring problem on your hands. I would not even see it as a language change, but would compare it to C and C++ compilers turning -Wall -Werror on as mandatory flags in the latest release. It would be sort of "good for the ecosystem" in the long term, but would also be a lot of effort for people with legacy codebases.

saurik 10y ago
The fact that you could choose to be that careful with Unicode in Python 2.7, though, is important to not forget: if the only change was that now you had to be, then code could have easily migrated and worked on both. This was the story of Ruby 1.9, which was, compared to Python 3, a cakewalk. The reality here is that you are just wrong in both understanding and premise :/. First, all these minor changes are actually extremely serious, as they made it hard to impossible to have cose which ran on both; as someone who was nowhere near an expert in Ruby, it was still easy to write code which straddled the boundary between 1.8 and 1.9. Ruby 1.9 really could be seen as a set of "warnings" on 1.8. Second, the most serious change in Python 3 was not Unicode, it was actually the way it handled generators and iterators and lists in various contexts: this was a set of changes which broke lots of code in subtle ways and which could not be handled using your argument of search and replace (and which contributed to the awkwardness of having code running on both 2 and 3 at the same time).