The Python Road Not Taken
aleph.nu
aleph.nu
Porting was at least possible. Two years ago, I took a look at doing this, and there weren't enough modules ready to even attempt it. Now there are. There is progress. Slow progress.
The download statistics tell the story: "We can see that in the past year Python 3.x has grown from roughly 2% of the total downloads from PyPI to roughly 5-6%."[2] That's why the external modules don't work reliably on Python 3. 95% of the package use is on Python 2. Python 2 use is probably higher than that, since those are download statistics; PyPI doesn't see packages downloaded long ago and still running.
There's extensive denial about this among Python fans. That's a big part of the problem. Another problem is that PyPI is just a link farm - unlike CPAN, it doesn't centralize code hosting, bug tracking, support forums, and quality control. This allows Python fans to be unaware of how buggy the packages are.
[1] https://news.ycombinator.com/item?id=9378898, search for "quality control" [2] https://caremad.io/2015/04/a-year-of-pypi-downloads/
My stubbornness is rooted in the simplicity of print. It is so simple and stupid, why change it? Never has a production app relied heavily on print, it's just a dumb way to check shit while developing. I mean sweet jesus if it ain't broke right? I know I'm wrong in thinking this kind of thing happened everywhere in the 2->3 increment, but as I said earlier, I'm under no illusion of rationality. Python 3 broke hello world, and that just skeeves me out.
Eventually I'll write new stuff in 3, probably sooner rather than later especially with asyncio et all, but for now I'll stick with 2.
print "hello world" print("hello world")
[1] http://lucumr.pocoo.org/2014/5/12/everything-about-unicode/
Again, with the encoding the api is different, but it's still really simple.
These feel like walls for walls sake.
For encoding it's mainly annoying because now I have to manually add an import, which is more typing than before. To be fair, there is a cogent argument that my issues with both print and this mean what I really want is a different language altogether: one that, respectively, allows omitting parentheses for all function calls, and has some kind of implicit import. But other languages have their own problems, and this still feels like a paper cut.
Oh, and the annoyance is exacerbated by the interfaces of binascii.hexlify and base64.b64encode being broken. They both return bytes objects, which is dumb since the whole point of hex and base64 encoding is to represent binary data as text, and the most common thing to do with encoded strings is to insert them in the middle of other text. 'foo %s' % hexlify(b'bar') => "foo b'626172'"; to get the "foo 626172" I want, I have to do even more typing and append .decode('ascii').
sorted(records, key=lambda r: (r.city, r.age, r.name))
Encoding-wise, hex and base64 are not something I do too often, so their new interfaces don't worry me too much. In the cases you've mentioned you could create a simple wrapper function to deal with it for you.
I guess there's some reason for using bytes instead of strings as the output to the interface, but, as you say, it's definitely non-obvious.
There are lots of things that are a little different in python 3; I would say overwhelmingly for the better, on the whole. There just doesn't seem to be much point fighting against those minor changes when they're easy enough to adapt to.
Python 3 broke hello world
Python 3 broke hello world
Python 3 broke hello world
...
People say "print became a function", but that doesn't do it justice. Your quip is infinitely better.
I'm seeing an awful lot of green there. Most of the things that are red (which might influence someone to use Python 2 on a greenfield project) have alternatives that are green.
Also, Oath2 seems like a big one, and would exclude many other packages that might use it.
I've been looking at porting all the flask-websocket stuff over by using guv as a base. Haven't done anything other than reading codebases but it looks like it should make it easy.
5000 packages converted, 55,000 to go. If you can't port until somebody else does, then projects that depend on you can't convert. Guido talks about this, and says more than "looks green to me".
however, the vast overwhelming vast huge vast majority of software in the world is legacy systems. software lifecycles are long and the cost of migrating from Python 2 to Python 3 is very high for those systems.
I remember, when Py3 first came out, everything was incompatible -- unnecessary incompatibilities like the u" notation for Unicode string literals that was dropped. Unnecessary incompatibilities in the C-extension-module implementation layer. And so on. The list of incompatibilities was just huge.
Later several of them where dropped, like the string literal trouble ... But than the trouble was already done. Many extension modules where not lifted to the new version, since the overhead was to big.
I think, many more projects would have adopted Py3, if more extension modules would support it.
The huge library of extension modules was always the strength of Python. Now we have many projects still running on Py2, because Py3 did ignore this strength.
I think, when it would have cared more for compatibility from the beginning, much of the damage done would have been avoided.
I've been programming for almost 20 years but am new to Python. I'm currently working on an API for a product and testing it against 2.7 and 3.4. It's not the end of the world, and if it works for 3.4 it pretty much works in 2.7. Granted, it's not the world's most complex or deep piece of python, but is there a real problem in making 2.X code run on 3.X? Is it really that big of a change?
I also provide binaries for all the Python versions in both 32 bit and 64 bit (where relevant) for Windows. When hosted on Google Code, their download stats showed the vast majority on Python 2.7 32 bit with a slow increase in 2.7 64 bit. Python 3.x downloads were roughly similar to Python 2.4 downloads! Sadly since moving to Github I have no idea what the download rates are.
BTW the only reason for not supporting Python 3.0 was that the test suite needed a module that wasn't provided (base64 or something similar), which I could have worked around, but the 3.0 release was end of lifed so I didn't bother.
Wow, that's remarkably unconvincing. I'll think of this the next time I hear of some complex ethical dilemma solved by asking a small child.
That said, who is central enough to put an "end" date on Python and "force" people to move over?
Guido van Rossum?
I'm not in the Python community - I barely know the language itself - but from the outside he seems to be a central figure? Doesn't he have enough authority to pull this off?
The thing is there is no "community". There's a core team, smaller teams around some projects with their own ideas, and a huge number of individuals and companies using Python, each with their own needs, use cases and timelines...
That's why there is still lots of COBOL in the world and why Python 2.x is going to live for many years, far past the 5 year predicted end of life. It will be far cheaper to make new releases of Python 2.x than to port the millions of lines of existing code.
Python 3 is nice, take a look at it. It probably will be easier porting than you think. However, don't feel like you are forced into moving to it. Python 2.x will continue to be around.
I thought the premise of building the new road was because the old road's ground wasn't good enough, not that there was too much traffic and the road needed more lanes.
Anyway, the whole thing hinges on the authors assertion that the new road isn't that much better, so it's really up to the informed developer/user to decide whether or not they take the new road.
Another person asserting that Python 3 is going nowhere, based on their opinion and nothing more, no science, no facts, no figures.
Without any reasonable justification for this opinion then I call this complete FUD and to be entirely disregarded.
I just can't get myself interested in rolling my own packages for the dozens of libraries I depend on, especially since they already "just work" with Python 2.
What planet does the author live on?
If this is a frequent challenge, it sounds like there's some technical debt to pay down elsewhere in your testing/deployment practice because it really doesn't need to be that hard.
`psycopg2` is a pip package that won't install without system dependencies. Yes, I use Ansible and the system dependencies are managed. But, out of the box, on a clean system, `pip install psycopg2` doesn't just work.
If you mean adoption by businesses and entities using it in their infrastructure, then no, the author is correct: We're not seeing much progress there.
It seems like the same attitude as the GNOME developers .. (disclaimer I use both GNOME and python, I must be a mashochist).
The API is tiny, and the result is beautiful.
If you haven't seriously tried using it to implement something that really benefits from such computer science innovation, then you have simply seen nothing of Python 3 yet. There are many types of logic that are vastly simplified with such a programming paradigm. Faster to code, and far simpler to debug. By orders of magnitude. One example you could try if you cannot envision one is to implement a high performance network protocol. I for instance implemented the SSH protocol from scratch (RFCs) in a matter of weeks. I though it would take months before I tried, especially since I had never programmed in Python before! As I said, the API is tiny. Learning it (Python and Asyncio at once) was so easy and ended up taking such an insignificant amount of time compared to the vast quantities of time and headache saved, that, well, I just had to write this post with all that extra time and energy!
Check it out! You will find that it is beyond worth just addressing whatever fears or problems you have with making the switch.
http://sahandsaba.com/understanding-asyncio-node-js-python-3...
1) debugging is way better in asyncio, with ipdb you can step in co-routine. In twisted, you will end up somewhere in internals.
2) asyncio is end of unhanded error in deferred :) (or you need to remember to add addErrback everywhere, even after addColbecks and addBoth)
3) with trial testing is frustrating, sometimes error raised in wrong test because of global event loop (for instance you forgot to mock external call). In asyncio world loop passed explicitly and this is good for testing.
I'm hoping that aiohttp, or a similar library, further matures and we start seeing apps built on it. Developing asynchronous HTTP code in Python 2.x is significantly harder than throwing together a Node app, where things are "asynchronous by default" (unlike, say, Flask or Django). Having a universal, built-in event loop removes a huge point of confusion and learning for async development in Python, and can hopefully bring interest from developers who would normally look to Node.
I'll be releasing the greater project shortly as GPL, with the SSH implementation as LGPL! I'll announce on HN for sure then.
Guido, if you want to put it in Python itself, you can have it in whatever license you need for that.
[1] http://compiletoi.net/fast-scraping-in-python-with-asyncio.h...