4 ms·

Python really should learn from PHP7. Yes, it breaks a lot of things, but it's totally worth it for the performance gains. Py3k solves problems partially like

by est 10y ago

Python really should learn from PHP7. Yes, it breaks a lot of things, but it's totally worth it for the performance gains. Py3k solves problems partially like Unicode or async/await but it's a non-issue for skilled python2 developers. People like incentives to upgrade. Period.

eeZi 10y ago
Lots of incentives for us: - clean Unicode support which prevents mistakes which used to bite us in production - native async syntax, compatible with Tornado - asynchronous generators (yield from a coroutine!) - pathlib and os.scandir - type annotations - matrix multiplication - chained exceptions - faster dicts, ordered by default So many useful features, and with the latest Python 3 releases porting has become really easy thanks to improved compatibility with the old syntax.
- icegreentea 10y ago
  They are all pluses, but most of those didn't exist till the last couple years. So effectively the first 6 or so years of Python 3 existing had much less incentive. I think the flip around - ~30% adoption of a newest version at 1-2 years in - especially one that breaks backwards compatibility isn't bad. I've started numerous python projects at work over the last year all on 2.7. I think we just started the last one. We're finally ready to jump to 3.
  - dr_zoidberg 10y ago
    Indeed, and ordered dicts come from Py 3.6, which is in beta now and expected for December. If async and this had been in Py3 from the start, they could've done a far better argument saying "hey, we broke all this stuff, but you get asyinc I/O and faster dicts" (a note of faster dicts: since many classes and language mechanisms use dicts, it should have an encompassing effect on all of python performance -- maybe not 30% or 40% faster, but a few % all around, which is kind of what micro benchmarks are showing with 3.6 betas)
- est 10y ago
  All of these incentives you listed are also doable in Py2k.
  - poooogles 10y ago
    Native Async syntax won't be doable in Python 2.
    - est 10y ago
      We have gevent, tornado, twisted, pyuv.
rburhum 10y ago
This is spot on. What if I am not running into any significant Unicode issues for the past 6 years?? (insignificant == stuff I can fix in 10 minutes). What if async/await has been achieved through other libraries (e.g. GEvent, threadpools, whatever)... What is the incentive to switch a large (working) codebase?
- sametmax 10y ago
  The code is just easier to maintain and debug. Unicode (which is a HUGE deal for a french like me) is not the only thing that has been fixed in Python 3. A lot of bugs disappear (the API is unified, division is true by default, imports are absolute), or are easier to detect (clear exception if you compare incompatible types, bytes are very explicit). Many duplicate ways of doing things are removed (modules are renamed, builtins have been cleaned up), the syntax is terser (no more object in class, no more from __future__, super() has a shorthand, no more # coding, not more u''). It's easier to write lower memory code (most things are generators by default, yield from allow to delegate to sub generator). Creating clean library is also much easier. Now I'm playing with type hints, and yes, it does help to avoid bug. "raise from" makes error reporting much better. No relative imports make organizing code much easier. Basically everytime I go back to Python 2, it feels like a pain. So many little things I didn't notice, take for granted, but that adds up quickly. The worst being of course to code a 2/3 compatible code and to have to do things like: https://github.com/Tygs/ww/blob/master/src/ww/types.py https://github.com/Tygs/ww/blob/master/src/ww/types.py. But I do it only for libs that I want to use specifically to help me migrating project (ww wraps everything the same way in 2 and 3, making migrating easier). I look forward for 3.6 to introduce f-strings, which I will adopt asap because it's so convenient.

by est 10y ago

eeZi 10y ago

Lots of incentives for us: - clean Unicode support which prevents mistakes which used to bite us in production - native async syntax, compatible with Tornado - asynchronous generators (yield from a coroutine!) - pathlib and os.scandir - type annotations - matrix multiplication - chained exceptions - faster dicts, ordered by default So many useful features, and with the latest Python 3 releases porting has become really easy thanks to improved compatibility with the old syntax.

icegreentea 10y ago
They are all pluses, but most of those didn't exist till the last couple years. So effectively the first 6 or so years of Python 3 existing had much less incentive. I think the flip around - ~30% adoption of a newest version at 1-2 years in - especially one that breaks backwards compatibility isn't bad. I've started numerous python projects at work over the last year all on 2.7. I think we just started the last one. We're finally ready to jump to 3.
- dr_zoidberg 10y ago
  Indeed, and ordered dicts come from Py 3.6, which is in beta now and expected for December. If async and this had been in Py3 from the start, they could've done a far better argument saying "hey, we broke all this stuff, but you get asyinc I/O and faster dicts" (a note of faster dicts: since many classes and language mechanisms use dicts, it should have an encompassing effect on all of python performance -- maybe not 30% or 40% faster, but a few % all around, which is kind of what micro benchmarks are showing with 3.6 betas)
est 10y ago
All of these incentives you listed are also doable in Py2k.
- poooogles 10y ago
  Native Async syntax won't be doable in Python 2.
  - est 10y ago
    We have gevent, tornado, twisted, pyuv.

rburhum 10y ago

This is spot on. What if I am not running into any significant Unicode issues for the past 6 years?? (insignificant == stuff I can fix in 10 minutes). What if async/await has been achieved through other libraries (e.g. GEvent, threadpools, whatever)... What is the incentive to switch a large (working) codebase?

sametmax 10y ago
The code is just easier to maintain and debug. Unicode (which is a HUGE deal for a french like me) is not the only thing that has been fixed in Python 3. A lot of bugs disappear (the API is unified, division is true by default, imports are absolute), or are easier to detect (clear exception if you compare incompatible types, bytes are very explicit). Many duplicate ways of doing things are removed (modules are renamed, builtins have been cleaned up), the syntax is terser (no more object in class, no more from __future__, super() has a shorthand, no more # coding, not more u''). It's easier to write lower memory code (most things are generators by default, yield from allow to delegate to sub generator). Creating clean library is also much easier. Now I'm playing with type hints, and yes, it does help to avoid bug. "raise from" makes error reporting much better. No relative imports make organizing code much easier. Basically everytime I go back to Python 2, it feels like a pain. So many little things I didn't notice, take for granted, but that adds up quickly. The worst being of course to code a 2/3 compatible code and to have to do things like: https://github.com/Tygs/ww/blob/master/src/ww/types.py https://github.com/Tygs/ww/blob/master/src/ww/types.py. But I do it only for libs that I want to use specifically to help me migrating project (ww wraps everything the same way in 2 and 3, making migrating easier). I look forward for 3.6 to introduce f-strings, which I will adopt asap because it's so convenient.