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