7 ms·

> Frankly, I still haven't seen a single reason to switch to Python3 beyond the fact that the original authors have gotten bored of providing security and bugfi

by nas 9y ago

> Frankly, I still haven't seen a single reason to switch to Python3 beyond the fact that the original authors have gotten bored of providing security and bugfix updates and will stop in 2020. That's it. It seems pretty clear now that 3rd party library developers are going to stop releasing packages that support 2.x and target only 3.x. Isn't that a bigger problem for Python 2.7 hold outs? Originally, I was not super excited about Python 3. I liked "print" as a keyword. I liked the space efficiency and speed of latin-1 strings by default. I did a lot of network protocol stuff and bytes() was a pain to use. I knew how to use the 'u' prefix to get unicode when I needed. However, after using Python 3 for a few years now, I find Python 2 clumsy. Print as a function is better. Unicode works better. The implementation is just as fast or faster than Python 2 and getting faster every release. If you tried Python 3 a few releases ago, you should give it another go. It has matured a lot.

Figs 9y ago
> Isn't that a bigger problem for Python 2.7 hold outs? Yes, but it seemed like libraries (such as NumPy here) were mainly switching because of the EOL of Python2 rather than for any actual benefit provided by Python3. I've considered that as more of "Python 3 is a bad thing" by splitting the ecosystem further, and creating additional churn and rework of existing projects. Thus my question of why people seem to think this is a good thing now -- i.e. what has changed in Python 3.6 that they're happy to do this now when they were pissed off about it a couple years ago? I've gotten a couple interesting responses here, and I hope for more. I wasn't really aware of f-strings -- that does seems like a nice-to-have feature -- and I wasn't aware of improved JSON serialization performance either. > If you tried Python 3 a few releases ago, you should give it another go. It has matured a lot. I may do that.
- skierscott 9y ago
  > what has changed in Python 3.6 that they're happy to do this now when they were pissed off about it a couple years ago? Most of mine have to do with developer productovity and I didn’t find until Python 3.5. – @, the matmul operator – fstrings (f”{foo}”) – parameter typing (foo: int = 0) which has exciting work with Cython – other async features. I forget what library it was (tensorflow?) but for Python 3 it had better async support
  - JoBrad 9y ago
    pathlib is pretty awesome, too. Has some growing pains, to be sure, but overall it makes paths so much easier than without it.
  - pfranz 9y ago
    I haven't jumped into Python3 yet (for work/legacy reasons), but I'm really looking forward to nested exceptions and pathlib. Also, even when just working in English, unicode (or special classes for strings) were really annoying when interfacing with other libraries like Qt or databases.
  - x14 9y ago
    Don't forget how nice super().__init__() is.
    - speedplane 9y ago
      The double underscore methods are some of the ugliest parts of Python. If they were going to break compatibility, I'd get rid of them too.
      - m_mueller 9y ago
        I think you're right, only this wouldn't require breaking compatibility. It doesn't even require a python upgrade, you could just make a base class that remaps nicer named functions to the standard ones, like baseclass.is_lower_than = baseclass.__lt__
        speedplane 9y ago
        You're probably right. Sadly, the vast majority of the python upgrades probably did not require breaking compatibility. Or if they did, they weren't worth it. I understand that iterators are arguably better than lists and print should arguably be a real function, but those advantages are far too small to justify breaking compatibility.
  - cdelsolar 9y ago
- takeda 9y ago
  > Yes, but it seemed like libraries (such as NumPy here) were mainly switching because of the EOL of Python2 rather than for any actual benefit provided by Python3. Actually if you ever wrote code that you wanted to make backwards compatible with Python 2.7 is a nightmare. The fact that they did not even wait until 2020 before depreciating it is a testament to that. > I've considered that as more of "Python 3 is a bad thing" by splitting the ecosystem further, and creating additional churn and rework of existing projects. Thus my question of why people seem to think this is a good thing now -- i.e. what has changed in Python 3.6 that they're happy to do this now when they were pissed off about it a couple years ago? I don't know about others, I always been supporting Python 3 since 3.4. I feel like many people were complaining about Python 3, but never used it, then eventually started using and realized that it is not so bad. > I may do that. You should, is much more enjoyable experience. Perhaps because you're so used to Python 2, you don't notice, but Python 2 has a lot of warts that accumulated over the years.
- HelloNurse 9y ago
  There should have been more innovation, making Python 3 compelling enough for Numpy use to deprecate Python 2 in 2010 for obvious, noncontroversial technical reasons. Instead there has been a thoroughly unpleasant and glacially slow transition between "we have to support Python 3 for bleeding edge users" to "we have to support Python 2 for retro users".

by nas 9y ago

Figs 9y ago

> Isn't that a bigger problem for Python 2.7 hold outs? Yes, but it seemed like libraries (such as NumPy here) were mainly switching because of the EOL of Python2 rather than for any actual benefit provided by Python3. I've considered that as more of "Python 3 is a bad thing" by splitting the ecosystem further, and creating additional churn and rework of existing projects. Thus my question of why people seem to think this is a good thing now -- i.e. what has changed in Python 3.6 that they're happy to do this now when they were pissed off about it a couple years ago? I've gotten a couple interesting responses here, and I hope for more. I wasn't really aware of f-strings -- that does seems like a nice-to-have feature -- and I wasn't aware of improved JSON serialization performance either. > If you tried Python 3 a few releases ago, you should give it another go. It has matured a lot. I may do that.

skierscott 9y ago
> what has changed in Python 3.6 that they're happy to do this now when they were pissed off about it a couple years ago? Most of mine have to do with developer productovity and I didn’t find until Python 3.5. – @, the matmul operator – fstrings (f”{foo}”) – parameter typing (foo: int = 0) which has exciting work with Cython – other async features. I forget what library it was (tensorflow?) but for Python 3 it had better async support
- JoBrad 9y ago
  pathlib is pretty awesome, too. Has some growing pains, to be sure, but overall it makes paths so much easier than without it.
- pfranz 9y ago
  I haven't jumped into Python3 yet (for work/legacy reasons), but I'm really looking forward to nested exceptions and pathlib. Also, even when just working in English, unicode (or special classes for strings) were really annoying when interfacing with other libraries like Qt or databases.
- x14 9y ago
  Don't forget how nice super().__init__() is.
  - speedplane 9y ago
    The double underscore methods are some of the ugliest parts of Python. If they were going to break compatibility, I'd get rid of them too.
    - m_mueller 9y ago
      I think you're right, only this wouldn't require breaking compatibility. It doesn't even require a python upgrade, you could just make a base class that remaps nicer named functions to the standard ones, like baseclass.is_lower_than = baseclass.__lt__
      - speedplane 9y ago
        You're probably right. Sadly, the vast majority of the python upgrades probably did not require breaking compatibility. Or if they did, they weren't worth it. I understand that iterators are arguably better than lists and print should arguably be a real function, but those advantages are far too small to justify breaking compatibility.
- cdelsolar 9y ago
takeda 9y ago
> Yes, but it seemed like libraries (such as NumPy here) were mainly switching because of the EOL of Python2 rather than for any actual benefit provided by Python3. Actually if you ever wrote code that you wanted to make backwards compatible with Python 2.7 is a nightmare. The fact that they did not even wait until 2020 before depreciating it is a testament to that. > I've considered that as more of "Python 3 is a bad thing" by splitting the ecosystem further, and creating additional churn and rework of existing projects. Thus my question of why people seem to think this is a good thing now -- i.e. what has changed in Python 3.6 that they're happy to do this now when they were pissed off about it a couple years ago? I don't know about others, I always been supporting Python 3 since 3.4. I feel like many people were complaining about Python 3, but never used it, then eventually started using and realized that it is not so bad. > I may do that. You should, is much more enjoyable experience. Perhaps because you're so used to Python 2, you don't notice, but Python 2 has a lot of warts that accumulated over the years.
HelloNurse 9y ago
There should have been more innovation, making Python 3 compelling enough for Numpy use to deprecate Python 2 in 2010 for obvious, noncontroversial technical reasons. Instead there has been a thoroughly unpleasant and glacially slow transition between "we have to support Python 3 for bleeding edge users" to "we have to support Python 2 for retro users".