6 ms·

> "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 wer

by 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.)

by p-e-w 4y ago

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.)