Also, as a library developer, I wanted to highlight some facts from experience with Python 2/3 development:
- Travis CI is an invaluable resource for running your test suite on a number of Python versions at once. It has deep integration with GitHub, and together they make the development flow a lot less cumbersome.
- Writing to a subset of Python that is compatible with both 2.7 and 3.3+ is not terribly hard. Lots of resources exist out there, including Armin's porting guide, six, python-future, and eight (https://github.com/kislyuk/eight).
- Contrary to some opinions out there, Python 3 actually makes working with Unicode a lot less perilous than Python 2, mostly by having a sane encoding default (UTF-8 instead of Python 2's ascii) and not doing automatic bytes/unicode coercion.
- PyPy is awesome and just released their first non-beta Python 3 version. Please donate!
I guess I'm in the minority here of being a full time python developer and thinking 1) these are all totally unexciting for day to day python use, and 2) the only actually interesting one (async io) is covered with:
Not going to lie to you. I still don't get this.
...which is not really a call to arms for py3 as far as I'm concerned.
(pypy support and potentially having one binary running 2.7 and 3.x at the same time is much more exciting)
I'm exactly in the same boat than you. Worst, I do believe that, even if the API is nice, asyncio belongs to the old past way of doing concurrency, I want actor models and/or STM with feature like the ones found in clojure.
Python core devs really miss the point that if you want people to move from one solution to another with a cost (here: breaking backward compatibility) you have to provide an high value reason to move (see the network effect). Here we only got minor (but cool) improvements, moving to python3 is just not worth it. It's like having to do a plain old boring homework imposed by a teacher with the only reason "because I told you to" (and the situation is even worst if you have to do compatible code for libs).
I'm not at all against breaking backward compatibility, you have to have a good reason and to make it worth it and, of all the (minor) improvements I see, none of them was a justification for this. Tell me things like "oh, we break backward compatibility because we want to drop the GIL and implement the erlang actors model natively in python" and I'm with you the day it's released (even if you don't provide automatic CPU balancing at the beginning).
I think asyncio + "yield from" is the killer feature for Python 3.x right now. (It's covered briefly in these slides.)
Beazley gives it a very detailed treatment in this amazing YouTube video, which covers not only asyncio's internal implementation, but also explains what coroutines are and when you'd actually benefit from using them in async programming:
Chained exceptions* is fantastic. I've found myself handling a specific set of exceptions, logging/printing various pieces of the traceback, and continuing on more times that I'd care to think about. This provides the level of context to the exception I'd have wanted.
Combined with fine grained `oserrors`, that's awesome. I have so much magic `errno` checking code over the years.
It’s not really a feature, it’s an operator that can be overloaded. That is, instead of using `mymodule.dot(a, b)`, you can use the much less readable `a @ b`.
> Feature 1: Advanced unpacking
> Refactor your functions
The given example is a bad refactoring, because it moves away the function’s self-documentation.
> It’s not really a feature, it’s an operator that can be overloaded. That is, instead of using `mymodule.dot(a, b)`, you can use the much less readable `a @ b`.
I disagree with you, and think it's definitely a feature. If you are doing scientific computing it can be much more readable to use infix overloaded operators. What is better, `np.dot(x.T(), np.dot(M, x))` or `x.T() @ M @ x`? I find the second much more readable.
I get it that operator overloading can be abused and lead to unreadable code, but in some use cases it is a godsend.
Too little too late and not good enough,very little offered for splitting the user base.
Python in the long run is badly positioned as
1. Moores law partytime is over. Performance matters again and the language has significant upper limits on speed.PyPy is not fast enough and further splits the user base.
2.As performance matters again concurrency matters more,concurrency in python in horribly implemented.
3.AsyncIo, What the hell am I even looking at? Gevent is vastly simpler than this.
It is a pity as it is one of the cleanest languages around and a joy to code in.
But programmer productivity is more important than speed you say? We in many cases that is true but languages like go and Julia can offer both so why program in a slow language which you may have to replace later when its almost as easy to take another option and have everything?
I really don't see how PyPy is "splitting the user base" when you have to make close to no changes to your code to gain an appreciable speedup in 90% of the cases.
I see many people compare Python to Go and frankly? Go isn't nearly as nice to work with as Python (no exceptions? one among many small but noticeable annoyances). It's much nicer than C or C++ in cases where you require the raw performance but it isn't a replacement for Python.
There are also many areas where performance is literally of zero consideration (small scripts to automate stuff) and those areas are where Python is hard to beat.
Pypy3 + STM is coming, which should resolve your first two points. Pypy is fast enough for most, and is gradually getting faster. I don't see at all how it splits the user base.
With regards to asyncio, a lot of people would disagree with you.
Too little too late? Maybe...that's for you to decide. Yes, there are new competitors that didn't exist when the decision was made to pursue the Python 3 strategy. But Julia has nothing close to the standard library + ecosystem that Python does, and probably won't for a long time if it ever does; and while Go is coming along in that regard, there are some aspects that make it less preferable to Python, especially JITed Python with software transactional memory (i.e. no GIL). I, for one, would never want to code without exceptions if I had the choice.
> PyPy is not fast enough and further splits the user base.
There is no split?
> Gevent is vastly simpler than this.
I prefer asyncio's explicitness to gevent's monkey-patch-and-pray-it-doesn't-block semantics. Also, the asyncio approach makes it very clear when you have released the "lock" on your state--it happens every time you yield from your coroutine. The gevent approach is to hide these synchronization points, which I think is a bad policy. For what it's worth this latter objection is one of the main reasons asyncio is the way it is--GvR had been bitten before by implicit yields.
I find no reason whatsoever to move to Python 3. These
"features" offer nothing of substance to me and my typical
workload with Python. Finally, Unicode handling in
Python 3 is a huge mess.
Can you cite me 10 awesome and useful libraries that haven't been ported to Python 3 and don't have reasonably equal alternatives?
I know there are some critical libraries to some niches who don't particularly care about recent versions. I know there's a fair amount of libraries that don't work on Python 3 purely because the author used print instead of print(). I know there are apps that can't port to Python 3 because they were designed with some core Python 2 functionality a decade ago (usually unicode/bytes related).
None of these matter to real world devs. User-facing apps don't matter, easy-to-port libs don't matter (fork & fix), niche libs don't matter (if your niche doesn't care about Python 3, you're either here to troll or you're not actually here).
I know it's very "in" to say that Python 3 is dead-on-arrival and all that but it's simply untrue. Anyone who uses a Python 3-based Linux distribution will understand that. Most new devs use Python 2 because they are too lazy to install Python 3 and assume their code won't work; and as soon as they hit a SyntaxError in print they complain that "Python 3 is hard".
You see all these libraries in red? Most of them depend on each other (Twisted is a big one as well as another I forget about) and have excellent alternatives available. Good luck finding 10 that match my criteria; I can't even find one.
Myself, I was very skeptical, until one day I decided to start my new project in Python 3 and quickly realized that everything isn't that much ruined. Couple of pull requests here and there, could be worse (after reading some of the more... opinionated blog posts I expected something truly catastrophic).
But the new goodness in 3.4 is totally worth it, in my opinion.
If Python 3 is so wonderful, why are the Python 3 developers still using Python 2 in their toolchain? It's because it would reportedly take 1 man year to port Mercurial to Python 3.
If an organisation has lots of legacy Python code, it'll cost them a lot of effort to re-write it for Python 3, and for what? Programmers might be maybe 1% more productive in the new language than the old one. For most organisations, this would not make business sense.
If Go is so awesome, why are Go developers still using C in their toolchain?
That's a terrible argument. Of course it takes effort to port existing application and tools. In some cases, it might be worth it and in some cases, it might not be. Python 2.7 will always be available to run such tools and applications.
This is very different from the case of library developers that should port their libraries to Python 3 (or support both Python 2 and 3, this is not difficult) so that it's accessible to more code.
This isn't an argument at all when it comes to writing new stuff in Python 3.
Mercurial isn't part of Python, and is essentially a black box tool. We use mercurial for a C++ project at work. Does that make it a Python and C++ project? Obviously not.
You might as well argue that if Python3 were so great the devs wouldn't be using C and C++ in their toolchain, which is what most of the underlying operating system and tools are written in.
And in that case, the argument would apply to almost every language and implementation out there.
Because the auto-unicode of system interfaces is a PITA if you want to deal with opaque data which is either binary or an unknown encoding?
Because the incompatibility of unicode and bytes (b'x' != 'x') and the "everything must be unicode" dogma of the ecosystem make it impossible to use many libraries that previously worked just fine ignoring any non-ascii characters?
If nothing else, because it's really really annoying to have to write "b" in front of every string literal just so I'm actually dealing with strings, not text?
Unicode-by-default may be dandy for a web developer, but for using python for system applications and glue logic it just makes things difficult.
I will never move to python3 for as long as they've broken strings.
> It's because it would reportedly take 1 man year to port Mercurial to Python 3.
Source?
> If an organisation has lots of legacy Python code, it'll cost them a lot of effort to re-write it for Python 3, and for what?
No need to port code that doesn't get a lot of attention. But if you want new features of Python, then you just have to bite the bullet. Organisations upgrade hardware all the time. They upgrade their OS somewhat regularly (on the order of years, but still). You get to make a choice - stay current and supported, or don't.
As for me, I will be (and have been) writing new applications with python 3. But I still maintain and support a number of 2.7 apps which will probably never be upgraded.
> If Python 3 is so wonderful, why are the Python 3 developers still using Python 2 in their toolchain? It's because it would reportedly take 1 man year to port Mercurial to Python 3.
Why would that have anything to do with it? We didn't write it and don't have any input into Mercurial, and it works fine for what it's used for right now. It's a source control tool, not a library we use in any way.
If we did the subversion switch today, it'd be to git, which again has nothing to do with Python versions (obviously).
Good move. Infact I'll suggest that the devs have some courage and make it a new language entirely. Trying to keep python3 in an awkward backward compatibility is harming it. And remove the GIL limitation at all costs.
Now, does that identifier consist of three ascii letters, or 3 Cyrillic letters that happen to look the same, or some combination of the two? It's impossible to tell.
Supporting more than ascii in code is a wonderful, wonderful feature for some countries and opens up Python to people for whom the latin alphabet is as familiar as the [pick a non-latin alphabet you don't understand] is to you.
Would I use it? No. Would I work on code that used it? Not in three lifetimes. Do I like that it's there? Hell yes.
As the slides were showing, I can write shutil.rmtree("/"). Does that mean rmtree should prevent me from passing "/"?
There are countless examples of where allowing non-ASCII identifiers makes code more readable in non-English languages. For example a Brazilian coder might write
país = "Brasil"
Without the accent, pais means fathers rather than country.
Imagine how constraining it would be to code in a language that disallowed vowels in identifiers (perhaps because it had been designed by Hebrew speakers). That's how most of the world experiences Python 2.
[+] [-] ak217|11 years ago|reply
Another feature not in this talk is function annotations (http://legacy.python.org/dev/peps/pep-3107/) and things they enable like optional runtime type checking (https://github.com/kislyuk/ensure#enforcing-function-annotat...).
Also, as a library developer, I wanted to highlight some facts from experience with Python 2/3 development:
- Travis CI is an invaluable resource for running your test suite on a number of Python versions at once. It has deep integration with GitHub, and together they make the development flow a lot less cumbersome.
- Writing to a subset of Python that is compatible with both 2.7 and 3.3+ is not terribly hard. Lots of resources exist out there, including Armin's porting guide, six, python-future, and eight (https://github.com/kislyuk/eight).
- Contrary to some opinions out there, Python 3 actually makes working with Unicode a lot less perilous than Python 2, mostly by having a sane encoding default (UTF-8 instead of Python 2's ascii) and not doing automatic bytes/unicode coercion.
- PyPy is awesome and just released their first non-beta Python 3 version. Please donate!
[+] [-] shadowmint|11 years ago|reply
(pypy support and potentially having one binary running 2.7 and 3.x at the same time is much more exciting)
[+] [-] jlarocco|11 years ago|reply
Like replacing
with[+] [-] brabram|11 years ago|reply
Python core devs really miss the point that if you want people to move from one solution to another with a cost (here: breaking backward compatibility) you have to provide an high value reason to move (see the network effect). Here we only got minor (but cool) improvements, moving to python3 is just not worth it. It's like having to do a plain old boring homework imposed by a teacher with the only reason "because I told you to" (and the situation is even worst if you have to do compatible code for libs).
I'm not at all against breaking backward compatibility, you have to have a good reason and to make it worth it and, of all the (minor) improvements I see, none of them was a justification for this. Tell me things like "oh, we break backward compatibility because we want to drop the GIL and implement the erlang actors model natively in python" and I'm with you the day it's released (even if you don't provide automatic CPU balancing at the beginning).
[+] [-] natrius|11 years ago|reply
https://pypi.python.org/pypi/trollius
[+] [-] pixelmonkey|11 years ago|reply
Beazley gives it a very detailed treatment in this amazing YouTube video, which covers not only asyncio's internal implementation, but also explains what coroutines are and when you'd actually benefit from using them in async programming:
https://www.youtube.com/watch?v=5-qadlG7tWo
[+] [-] ibotty|11 years ago|reply
[+] [-] stephendicato|11 years ago|reply
Combined with fine grained `oserrors`, that's awesome. I have so much magic `errno` checking code over the years.
* https://asmeurer.github.io/python3-presentation/slides.html#...
[+] [-] hk__2|11 years ago|reply
It’s not really a feature, it’s an operator that can be overloaded. That is, instead of using `mymodule.dot(a, b)`, you can use the much less readable `a @ b`.
> Feature 1: Advanced unpacking
> Refactor your functions
The given example is a bad refactoring, because it moves away the function’s self-documentation.
[+] [-] fddr|11 years ago|reply
I disagree with you, and think it's definitely a feature. If you are doing scientific computing it can be much more readable to use infix overloaded operators. What is better, `np.dot(x.T(), np.dot(M, x))` or `x.T() @ M @ x`? I find the second much more readable.
I get it that operator overloading can be abused and lead to unreadable code, but in some use cases it is a godsend.
[+] [-] mhd|11 years ago|reply
[+] [-] Choronzon|11 years ago|reply
1. Moores law partytime is over. Performance matters again and the language has significant upper limits on speed.PyPy is not fast enough and further splits the user base.
2.As performance matters again concurrency matters more,concurrency in python in horribly implemented.
3.AsyncIo, What the hell am I even looking at? Gevent is vastly simpler than this.
It is a pity as it is one of the cleanest languages around and a joy to code in. But programmer productivity is more important than speed you say? We in many cases that is true but languages like go and Julia can offer both so why program in a slow language which you may have to replace later when its almost as easy to take another option and have everything?
[+] [-] ayrx|11 years ago|reply
I see many people compare Python to Go and frankly? Go isn't nearly as nice to work with as Python (no exceptions? one among many small but noticeable annoyances). It's much nicer than C or C++ in cases where you require the raw performance but it isn't a replacement for Python.
There are also many areas where performance is literally of zero consideration (small scripts to automate stuff) and those areas are where Python is hard to beat.
[+] [-] legutierr|11 years ago|reply
With regards to asyncio, a lot of people would disagree with you.
Too little too late? Maybe...that's for you to decide. Yes, there are new competitors that didn't exist when the decision was made to pursue the Python 3 strategy. But Julia has nothing close to the standard library + ecosystem that Python does, and probably won't for a long time if it ever does; and while Go is coming along in that regard, there are some aspects that make it less preferable to Python, especially JITed Python with software transactional memory (i.e. no GIL). I, for one, would never want to code without exceptions if I had the choice.
[+] [-] chrismonsanto|11 years ago|reply
There is no split?
> Gevent is vastly simpler than this.
I prefer asyncio's explicitness to gevent's monkey-patch-and-pray-it-doesn't-block semantics. Also, the asyncio approach makes it very clear when you have released the "lock" on your state--it happens every time you yield from your coroutine. The gevent approach is to hide these synchronization points, which I think is a bad policy. For what it's worth this latter objection is one of the main reasons asyncio is the way it is--GvR had been bitten before by implicit yields.
[+] [-] latiera|11 years ago|reply
Python is essentially dead as anything more than a scripting language.
[+] [-] latiera|11 years ago|reply
No thanks.
[+] [-] ekimekim|11 years ago|reply
...but you're right, it's not worth the unicode handling.
[+] [-] doreo|11 years ago|reply
[+] [-] scrollaway|11 years ago|reply
I know there are some critical libraries to some niches who don't particularly care about recent versions. I know there's a fair amount of libraries that don't work on Python 3 purely because the author used print instead of print(). I know there are apps that can't port to Python 3 because they were designed with some core Python 2 functionality a decade ago (usually unicode/bytes related).
None of these matter to real world devs. User-facing apps don't matter, easy-to-port libs don't matter (fork & fix), niche libs don't matter (if your niche doesn't care about Python 3, you're either here to troll or you're not actually here).
I know it's very "in" to say that Python 3 is dead-on-arrival and all that but it's simply untrue. Anyone who uses a Python 3-based Linux distribution will understand that. Most new devs use Python 2 because they are too lazy to install Python 3 and assume their code won't work; and as soon as they hit a SyntaxError in print they complain that "Python 3 is hard".
Here are the facts: https://python3wos.appspot.com/
You see all these libraries in red? Most of them depend on each other (Twisted is a big one as well as another I forget about) and have excellent alternatives available. Good luck finding 10 that match my criteria; I can't even find one.
[+] [-] bakareika|11 years ago|reply
Myself, I was very skeptical, until one day I decided to start my new project in Python 3 and quickly realized that everything isn't that much ruined. Couple of pull requests here and there, could be worse (after reading some of the more... opinionated blog posts I expected something truly catastrophic).
But the new goodness in 3.4 is totally worth it, in my opinion.
[+] [-] pixelmonkey|11 years ago|reply
https://python3wos.appspot.com/
It's mostly green. If there is a red one you really need, it's probably not hard to port it.
[+] [-] est|11 years ago|reply
[+] [-] EdwardDiego|11 years ago|reply
[+] [-] cabalamat|11 years ago|reply
If an organisation has lots of legacy Python code, it'll cost them a lot of effort to re-write it for Python 3, and for what? Programmers might be maybe 1% more productive in the new language than the old one. For most organisations, this would not make business sense.
[+] [-] ayrx|11 years ago|reply
That's a terrible argument. Of course it takes effort to port existing application and tools. In some cases, it might be worth it and in some cases, it might not be. Python 2.7 will always be available to run such tools and applications.
This is very different from the case of library developers that should port their libraries to Python 3 (or support both Python 2 and 3, this is not difficult) so that it's accessible to more code.
This isn't an argument at all when it comes to writing new stuff in Python 3.
[+] [-] jlarocco|11 years ago|reply
Mercurial isn't part of Python, and is essentially a black box tool. We use mercurial for a C++ project at work. Does that make it a Python and C++ project? Obviously not.
You might as well argue that if Python3 were so great the devs wouldn't be using C and C++ in their toolchain, which is what most of the underlying operating system and tools are written in.
And in that case, the argument would apply to almost every language and implementation out there.
[+] [-] ekimekim|11 years ago|reply
Because the incompatibility of unicode and bytes (b'x' != 'x') and the "everything must be unicode" dogma of the ecosystem make it impossible to use many libraries that previously worked just fine ignoring any non-ascii characters?
If nothing else, because it's really really annoying to have to write "b" in front of every string literal just so I'm actually dealing with strings, not text?
Unicode-by-default may be dandy for a web developer, but for using python for system applications and glue logic it just makes things difficult.
I will never move to python3 for as long as they've broken strings.
[+] [-] jsmeaton|11 years ago|reply
Source?
> If an organisation has lots of legacy Python code, it'll cost them a lot of effort to re-write it for Python 3, and for what?
No need to port code that doesn't get a lot of attention. But if you want new features of Python, then you just have to bite the bullet. Organisations upgrade hardware all the time. They upgrade their OS somewhat regularly (on the order of years, but still). You get to make a choice - stay current and supported, or don't.
As for me, I will be (and have been) writing new applications with python 3. But I still maintain and support a number of 2.7 apps which will probably never be upgraded.
[+] [-] briancurtin|11 years ago|reply
Why would that have anything to do with it? We didn't write it and don't have any input into Mercurial, and it works fine for what it's used for right now. It's a source control tool, not a library we use in any way.
If we did the subversion switch today, it'd be to git, which again has nothing to do with Python versions (obviously).
[+] [-] bpicolo|11 years ago|reply
It allows you to be agile about technologies without porting the world.
[+] [-] pekk|11 years ago|reply
Code which is costly to port won't be ported to anything, it will just sit there in its current state unless someone decides to port it.
[+] [-] melling|11 years ago|reply
[+] [-] js2|11 years ago|reply
Surprised no mention of concurrent futures, which also has a py2 backport - https://pypi.python.org/pypi/futures
[+] [-] manojlds|11 years ago|reply
[+] [-] bpicolo|11 years ago|reply
[+] [-] abhinavk|11 years ago|reply
[+] [-] ulam2|11 years ago|reply
[+] [-] badman_ting|11 years ago|reply
[+] [-] peaton|11 years ago|reply
[+] [-] abuddy|11 years ago|reply
[+] [-] BrandonLive|11 years ago|reply
Edit: I guess that's why the PDF link is there.
[+] [-] cmdrfred|11 years ago|reply
[+] [-] cabalamat|11 years ago|reply
In Python 3, identifiers don't identify!
[+] [-] scrollaway|11 years ago|reply
Supporting more than ascii in code is a wonderful, wonderful feature for some countries and opens up Python to people for whom the latin alphabet is as familiar as the [pick a non-latin alphabet you don't understand] is to you.
Would I use it? No. Would I work on code that used it? Not in three lifetimes. Do I like that it's there? Hell yes.
As the slides were showing, I can write shutil.rmtree("/"). Does that mean rmtree should prevent me from passing "/"?
[+] [-] jl6|11 years ago|reply
país = "Brasil"
Without the accent, pais means fathers rather than country.
Imagine how constraining it would be to code in a language that disallowed vowels in identifiers (perhaps because it had been designed by Hebrew speakers). That's how most of the world experiences Python 2.