15 ms·

IMO you're oversimplifying things without appreciating the scope of what went into Python 3. Core developer Brett Cannon's talk "Python 3.3: Trust Me, It's Bet

by gspetr 4y ago

IMO you're oversimplifying things without appreciating the scope of what went into Python 3. Core developer Brett Cannon's talk "Python 3.3: Trust Me, It's Better than 2.7" goes over most of the differences at the time (2013): https://www.youtube.com/watch?v=f_6vDi7ywuA https://www.youtube.com/watch?v=f_6vDi7ywuA

p-e-w 4y ago
> "Python 3.3: Trust Me, It's Better than 2.7" The fact that such a talk exists shows that the improvements aren't worth the switch for most users. If they were, they wouldn't need convincing. Yes, Python 3 is (mostly) better than Python 2. No, it's not even remotely worth the amount of confusion and work it caused. If Python 3 had brought massive performance improvements, or proper support for multiple threads, then maybe it would have been. As it stands, Python's biggest weaknesses remain unaddressed.
- EdwardDiego 4y ago
  > The fact that such a talk exists shows that the improvements aren't worth the switch for most users. If they were, they wouldn't need convincing. That's reading far too much into a tongue in cheek presentation title. Besides, good devs are typically reasonably skeptical of new and shiny. And when you've got a large Python 2.7 codebase, and Python 3 is backwards incompatible, you'd be looking at a lot of work to upgrade, so damn straight you'd need convincing to make the investment. Hell, look at how many Java codebases are still 1.8 because of the upgrade cost of going past that, even though modern Java has many compelling features. And expecting Python 3 to remove the GIL is incredibly unrealistic. How much Python code in the wild implicitly depends on the behaviour of the GIL? All of it.
  - mike_hock 4y ago
    > How much Python code in the wild implicitly depends on the behaviour of the GIL? About as much as depended on Python 2-specific features?
    - EdwardDiego 4y ago
      Sure, but the GIL behaviour is inherent to all concurrent (for a given value of concurrent) Python code. And code that could be run concurrently. Removing the GIL would be bloody fantastic, but it's far more involved than 2 to 3.
    - seba_dos1 4y ago
      A lot of codebases could be converted from Python 2 to Python 3 with just some fairly mechanical work and light refactoring on top. GIL would be a thing of a completely different magnitude.
      - tinus_hn 4y ago
        It’s so trivial! All that needs to happen is someone else putting in the work. And for free, please!
        chaosite 4y ago
        2to3 was always available to do that work, for free, yes.
  - debugnik 4y ago
    OCaml 5 recently solved the global lock problem by introducing concurrent domains in which one or more threads share a lock. So old code keeps spawning threads with a shared lock, but new code can work with single-thread domains and manage in which domains does old code run.
- dhdhdh 4y ago
  Python 3 paved the path for the changes that you mentioned you wished for, some of which are being tackled now. It's not only about what Python 3 offered at the time, but also about what it made possible in the long run.
  - Nullabillity 4y ago
    How does print-as-function help anyone remove the GIL?
    - pas 4y ago
      simpler code is always important to pave the way for innovation
    - thiht 4y ago
      Damn, get over it. Who cares that print is a function now?
      - jeltz 4y ago
        While that specific example is stupid the general question is very valid. I can't see what paved the way. The most invasive change was the unicode one and even that seems irrelevant to eg the GIL.
- forgotpwd16 4y ago
  >The fact that such a talk exists shows that the improvements aren't worth the switch for most users. More like it shows that many people like GP are only aware of the superficial changes.
- mattbillenstein 4y ago
  That's a bit cynical since I think if we were still dealing with the issues python 3 fixed today, I'd be very disappointed in python overall. And, the latest iterations of Python3 have real usability improvements - the error message improvements alone make development a lot nicer. And the perf improvements and jit coming I think in 3.13 will really make more people consider py3 for their new projects.
- mananaysiempre 4y ago
  > No, it's not even remotely worth the amount of confusion and work it caused. Have you worked with pervasively non-ASCII text in Python 2? Like on a machine where any file might suddenly turn out to be non-ASCII (even if it’s only in a comment), not just data inside a few carefully-patrolled fences? Outside of a few well-behaved libraries (Flask), my experience was that it was utterly impossible. More than half of my time debugging straightforward code was spent chasing down and fixing UnicodeErrors, knowing that some will still remain. And that includes code that used nothing but the standard library. Now you might think that’s not important, and though I disagree (especially when talking about “most users”) that would be fair. But it is a substantial improvement going from 2 to 3.
  - zarzavat 4y ago
    There is another universe where Python 3 only fixed the unicode strings, and the transition was a huge success and over in a couple of years. The print() function was absolutely not worth all the carnage it caused. They could have just kept the print statement around and introduced a printing function with a different name, for example. The fact that they removed syntax for Python 3 meant that all kinds of scientific computing code had to be transitioned even if it didn't use any strings!
    - chaosite 4y ago
      Wait, if it didn't use any strings, then it didn't use the print statement either, right?
      - zarzavat 4y ago
        For printing it's not a problem because a string containing unicode will be transparently printed in both Python 2 and 3 (at least on Linux/Mac, not sure how Windows deals with it). It's also not a problem if you only have ASCII strings.
    - IgorPartola 4y ago
      The print function was the simplest part of the transition. For one you could find and replace all instances of it fairly safely across your codebase and you could quickly discover any places where things broke because of a bad replace. That part took like an hour for a large codebase. The Unicode handling on the other hand took ages because string handling is not easily searchable and replacing it requires understanding what the piece of code actually does. So you have it exactly backwards: if the only migration was the print function then it would be a quick and relatively painless process. But fixing the hard thing which was the broken str/byte model was the hard transition. I am curious if you actually went through this transition or if your opinion on this is more based on observation of others’ work.
- raverbashing 4y ago
  I think the issue here is that Python 3.3 was more like 3.0-dev-rc3 The first python 3 versions were not great and were missing some things. I think 3.3 didn't even had pip builtin
- bb88 4y ago
  Would you still feel that way if Python had a series of upgrade versions that "hand-held" the migration and giving warnings about behavior that was going to break? I ask, because I know I would have wanted that.
- PurpleRamen 4y ago
  This talks title probably comes from the awful python 3.0+ versions. 3.0 was so bad, they had to fix and revive certain in the later versions. IIRC 3.3 was the first version who was considered decently enough, that someone you could use it for more serious things.
- rwalle 4y ago
  I bet that you did not watch the presentation. Also, the fact that there is a talk with such a name does not mean anything other than that someone is out there trying to clarify what the transition is about. (There could have been a video "Windows 7: Trust me, it's better than Windows XP" and you probably still would say that it showed that improvements aren't worth the switch for most users.)
tick_tock_tick 4y ago
Unless I'm missing something what in here supposed to justify a decade of pain? Hell most of it could have been easily done in python 2 and slowly via warning and errors transition codebases.
ilyt 4y ago
The changes Python made was made in Perl without breaking compatibility, you just wrote say use v5.24 in header to use given feature set (defaulted to something old to not break old stuff) The Py3 approach was terrible and wasted untold amount of hours just because you had to migrate everything, you couldn't just upgrade codebase piece by piece like in case of Perl. At the very least they should've just made new one be under .py3 and just make Python3 interpreter transpile Py2 code at runtime
- linsomniac 4y ago
  Isn't that effectively what was done with Python? You'd do "#!/usr/bin/env python" for old code and "#!/usr/bin/env python3" for new code. Rather than it being wrapped up in a single entry-point, you had the different runtimes and library sets.
  - acqq 4y ago
    No, it's completely different. The newer Perl versions correctly continued to execute the old but already working scripts. The Python mess was, IMO, a typical example of bureaucracy inventing for itself new but previously unnecessary work to justify its existence, so I agree that that the decisions of how to introduce Py3 features caused (and still cause) waste of immense amount of the hours world-wide that could have been used more productively. Sad.
    - spicybright 4y ago
      For sure. I'd argue it was debatable to even "normalizing" all the built in packages to be consistent. I think very few people had trouble remembering them, and if you're using one, you'll be looking up documentation for anything with more than a few methods. It really is frustrating in these situations with high level languages. It's super possible to do the majority of changes they did in non breaking ways. Hell, they do it already with the __future__ package. Where did all that compatibility work go in python3?
    - toast0 4y ago
      > No, it's completely different. The newer Perl versions correctly continued to execute the old but already working scripts. There was some breakage between 5.6, 5.8, and 5.10; Unicode is hard, and it takes time to get it right. But I think the key difference I've heard as a mostly python avoider is the intent was for code written for 5.6 to probably work in 5.8 and 5.10 and if it doesn't, for there to be a way to have one file that works for all versions. From what I understand, it's not easy to have a python module/script that works in 2 and 3, and you can't go to 3 unless your dependencies do, so if you have a lot of dependencies (as is modern), you're stuck on 2. Your dependencies won't want to move to 3 either, because their users are stuck on 2, so if they just switch to 3, they're droping users; instead they need to support two parallel versions of their code. Most perl modules didn't have to do anything special to support 5.6 and 5.8, but if they did, it was usually small and it could be done within the file with conditional compilation --- I don't think that was an option for python.

by gspetr 4y ago

p-e-w 4y ago

> "Python 3.3: Trust Me, It's Better than 2.7" The fact that such a talk exists shows that the improvements aren't worth the switch for most users. If they were, they wouldn't need convincing. Yes, Python 3 is (mostly) better than Python 2. No, it's not even remotely worth the amount of confusion and work it caused. If Python 3 had brought massive performance improvements, or proper support for multiple threads, then maybe it would have been. As it stands, Python's biggest weaknesses remain unaddressed.

EdwardDiego 4y ago
> The fact that such a talk exists shows that the improvements aren't worth the switch for most users. If they were, they wouldn't need convincing. That's reading far too much into a tongue in cheek presentation title. Besides, good devs are typically reasonably skeptical of new and shiny. And when you've got a large Python 2.7 codebase, and Python 3 is backwards incompatible, you'd be looking at a lot of work to upgrade, so damn straight you'd need convincing to make the investment. Hell, look at how many Java codebases are still 1.8 because of the upgrade cost of going past that, even though modern Java has many compelling features. And expecting Python 3 to remove the GIL is incredibly unrealistic. How much Python code in the wild implicitly depends on the behaviour of the GIL? All of it.
- mike_hock 4y ago
  > How much Python code in the wild implicitly depends on the behaviour of the GIL? About as much as depended on Python 2-specific features?
  - EdwardDiego 4y ago
    Sure, but the GIL behaviour is inherent to all concurrent (for a given value of concurrent) Python code. And code that could be run concurrently. Removing the GIL would be bloody fantastic, but it's far more involved than 2 to 3.
  - seba_dos1 4y ago
    A lot of codebases could be converted from Python 2 to Python 3 with just some fairly mechanical work and light refactoring on top. GIL would be a thing of a completely different magnitude.
    - tinus_hn 4y ago
      It’s so trivial! All that needs to happen is someone else putting in the work. And for free, please!
      - chaosite 4y ago
        2to3 was always available to do that work, for free, yes.
- debugnik 4y ago
  OCaml 5 recently solved the global lock problem by introducing concurrent domains in which one or more threads share a lock. So old code keeps spawning threads with a shared lock, but new code can work with single-thread domains and manage in which domains does old code run.
dhdhdh 4y ago
Python 3 paved the path for the changes that you mentioned you wished for, some of which are being tackled now. It's not only about what Python 3 offered at the time, but also about what it made possible in the long run.
- Nullabillity 4y ago
  How does print-as-function help anyone remove the GIL?
  - pas 4y ago
    simpler code is always important to pave the way for innovation
  - thiht 4y ago
    Damn, get over it. Who cares that print is a function now?
    - jeltz 4y ago
      While that specific example is stupid the general question is very valid. I can't see what paved the way. The most invasive change was the unicode one and even that seems irrelevant to eg the GIL.
forgotpwd16 4y ago
>The fact that such a talk exists shows that the improvements aren't worth the switch for most users. More like it shows that many people like GP are only aware of the superficial changes.
mattbillenstein 4y ago
That's a bit cynical since I think if we were still dealing with the issues python 3 fixed today, I'd be very disappointed in python overall. And, the latest iterations of Python3 have real usability improvements - the error message improvements alone make development a lot nicer. And the perf improvements and jit coming I think in 3.13 will really make more people consider py3 for their new projects.
mananaysiempre 4y ago
> No, it's not even remotely worth the amount of confusion and work it caused. Have you worked with pervasively non-ASCII text in Python 2? Like on a machine where any file might suddenly turn out to be non-ASCII (even if it’s only in a comment), not just data inside a few carefully-patrolled fences? Outside of a few well-behaved libraries (Flask), my experience was that it was utterly impossible. More than half of my time debugging straightforward code was spent chasing down and fixing UnicodeErrors, knowing that some will still remain. And that includes code that used nothing but the standard library. Now you might think that’s not important, and though I disagree (especially when talking about “most users”) that would be fair. But it is a substantial improvement going from 2 to 3.
- zarzavat 4y ago
  There is another universe where Python 3 only fixed the unicode strings, and the transition was a huge success and over in a couple of years. The print() function was absolutely not worth all the carnage it caused. They could have just kept the print statement around and introduced a printing function with a different name, for example. The fact that they removed syntax for Python 3 meant that all kinds of scientific computing code had to be transitioned even if it didn't use any strings!
  - chaosite 4y ago
    Wait, if it didn't use any strings, then it didn't use the print statement either, right?
    - zarzavat 4y ago
      For printing it's not a problem because a string containing unicode will be transparently printed in both Python 2 and 3 (at least on Linux/Mac, not sure how Windows deals with it). It's also not a problem if you only have ASCII strings.
  - IgorPartola 4y ago
    The print function was the simplest part of the transition. For one you could find and replace all instances of it fairly safely across your codebase and you could quickly discover any places where things broke because of a bad replace. That part took like an hour for a large codebase. The Unicode handling on the other hand took ages because string handling is not easily searchable and replacing it requires understanding what the piece of code actually does. So you have it exactly backwards: if the only migration was the print function then it would be a quick and relatively painless process. But fixing the hard thing which was the broken str/byte model was the hard transition. I am curious if you actually went through this transition or if your opinion on this is more based on observation of others’ work.
raverbashing 4y ago
I think the issue here is that Python 3.3 was more like 3.0-dev-rc3 The first python 3 versions were not great and were missing some things. I think 3.3 didn't even had pip builtin
bb88 4y ago
Would you still feel that way if Python had a series of upgrade versions that "hand-held" the migration and giving warnings about behavior that was going to break? I ask, because I know I would have wanted that.
PurpleRamen 4y ago
This talks title probably comes from the awful python 3.0+ versions. 3.0 was so bad, they had to fix and revive certain in the later versions. IIRC 3.3 was the first version who was considered decently enough, that someone you could use it for more serious things.
rwalle 4y ago
I bet that you did not watch the presentation. Also, the fact that there is a talk with such a name does not mean anything other than that someone is out there trying to clarify what the transition is about. (There could have been a video "Windows 7: Trust me, it's better than Windows XP" and you probably still would say that it showed that improvements aren't worth the switch for most users.)

tick_tock_tick 4y ago

Unless I'm missing something what in here supposed to justify a decade of pain? Hell most of it could have been easily done in python 2 and slowly via warning and errors transition codebases.

ilyt 4y ago

The changes Python made was made in Perl without breaking compatibility, you just wrote say use v5.24 in header to use given feature set (defaulted to something old to not break old stuff) The Py3 approach was terrible and wasted untold amount of hours just because you had to migrate everything, you couldn't just upgrade codebase piece by piece like in case of Perl. At the very least they should've just made new one be under .py3 and just make Python3 interpreter transpile Py2 code at runtime

linsomniac 4y ago
Isn't that effectively what was done with Python? You'd do "#!/usr/bin/env python" for old code and "#!/usr/bin/env python3" for new code. Rather than it being wrapped up in a single entry-point, you had the different runtimes and library sets.
- acqq 4y ago
  No, it's completely different. The newer Perl versions correctly continued to execute the old but already working scripts. The Python mess was, IMO, a typical example of bureaucracy inventing for itself new but previously unnecessary work to justify its existence, so I agree that that the decisions of how to introduce Py3 features caused (and still cause) waste of immense amount of the hours world-wide that could have been used more productively. Sad.
  - spicybright 4y ago
    For sure. I'd argue it was debatable to even "normalizing" all the built in packages to be consistent. I think very few people had trouble remembering them, and if you're using one, you'll be looking up documentation for anything with more than a few methods. It really is frustrating in these situations with high level languages. It's super possible to do the majority of changes they did in non breaking ways. Hell, they do it already with the __future__ package. Where did all that compatibility work go in python3?
  - toast0 4y ago
    > No, it's completely different. The newer Perl versions correctly continued to execute the old but already working scripts. There was some breakage between 5.6, 5.8, and 5.10; Unicode is hard, and it takes time to get it right. But I think the key difference I've heard as a mostly python avoider is the intent was for code written for 5.6 to probably work in 5.8 and 5.10 and if it doesn't, for there to be a way to have one file that works for all versions. From what I understand, it's not easy to have a python module/script that works in 2 and 3, and you can't go to 3 unless your dependencies do, so if you have a lot of dependencies (as is modern), you're stuck on 2. Your dependencies won't want to move to 3 either, because their users are stuck on 2, so if they just switch to 3, they're droping users; instead they need to support two parallel versions of their code. Most perl modules didn't have to do anything special to support 5.6 and 5.8, but if they did, it was usually small and it could be done within the file with conditional compilation --- I don't think that was an option for python.