It sparkled interesting discussions on HN:
https://news.ycombinator.com/item?id=6990481 "Python 2.x vs 3.x use survey"
https://news.ycombinator.com/item?id=7005711 " Python 2.x vs. 3.x survey results"
Here is the 2014 edition, slightly updated (from 9 to 11 questions).
It should not take you more than 1 minute to fill. I would be pleased if you took that time.
The results will be published around the end of the year.
Python 3 has better modules built-in; the existing modules have been cleaned up; a cleaned up language (no more xrange, lazy map/filter/reduce, explicit byte-stream encoding); an improved language (sub-generators); optional type annotations; configurable allocators (in Cpython).
I just prefer it to Python 2 these days.
edit: And all of the upstream effort into making the language better is going into Python 3.
>>> map(lambda i:i*i, range(5))
<map object at 0x010622F0>
>>> list(map(lambda i:i*i, range(5)))
[0, 1, 4, 9, 16]
That is indeed cleaner. Thanks for the explanation.
yield from traverse(tree.left)
yield from traverse(tree.right)
Same applies to map, filter and I believe reduce as well.
And that's the issue.You cant be a pro pythonist unless you know both,even if you prefer 3.x .Not saying 2.x is an entire different language.Still,Python devs have to know the differences between both versions.
and was confronted with
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x80 in position 2: invalid start byte
If I had realized at the time that this error would be averted with
I might have felt more charitable and less shocked (although I can see in retrospect that there's quite a good reason for this error, I might have preferred for the default file type to be binary -- presumably something that was debated extensively inside the Python 3 development effort).
This change only made that mistake visible on other systems.
Edit: Actually python doesn't even mention windows. It's simply "Add a 'b' to the mode for binary files." (in python 2.7 documentation) According to the docs it should be specified regardless.
Saves you from having to manage files at all, and works cross-platform.
In production code I would probably use Crypto.Random.get_random_bytes().
I have moved to Python 3 purely because of asyncio. There is no other reason that I have found Python 3 to be compelling for. When I write Python 3 now, I feel like my favourite language has gone all "serious" on me, like it wanted to grow up, and has lost a lot of its charisma on the way. I actually liked the print operator for example - it's probably the reason I chose python in the first place when I saw
>>> print "hello world"
3.0 has lost some of that. The unicode thing is also just irritating because 99% of the time ascii works very well and is less complicated, thank you very much.
Also, no matter what anybody says, you still bump into libraries that you need that are 2.x only (in my case Bloomberg). It doesn't matter if
most libraries are ported if just one library that you need is not ported yet, you're back to 2.x. Imagine you're an average coder who uses say 8 libraries. By the ratio of 15% not yet moved, you're almost certain to have a problem (1 - 0.85 ^ 8 > 70% chance). Anyway I have been able to manage because I have isolated the 2.x dependencies in another system, and I have put in the effort only because I really like asyncio, and it's finally clear to me that Python 2.x has no future. That said, and taking that logic even further, the very fact that this 2v3 issue is still around is irritating, and has been irritating a lot of people for a long time. I am wondering about going the whole way and moving to another language altogether (Golang and/or functionals).
One more thing to point out. If you're beginning in Python, the vast majority of code samples on the internet are 2.x. That's fine if you have any clue about Python as the surface differences are not that large, but it is definitely a pain if you're expecting to copy and paste and have things "just work".
Activating this option allows the parser to automatically infer function parentheses, just like in ruby. Though ruby still wins by virtue of its single letter `p` function.
In practice, the print statement is almost always much more convenient to use, but more than that, its removal represents to me the futility of the schism-- would it have hurt to let the canonical "hello world" continue to live as is?
It's an Ubuntu bug, not Python3. Install Python3 from python.org an everything is fine, except then apt-get of cause won't give you the bug fixes.
(Other comments suggest that there are fundamental problems with Python and virtualenv and Ubuntu, so either I just fortuitously missed all of that or maybe I was in such a happy delirium of tinkering that I've now forgotten all about it.)
sudo apt-get install python-virtualenv python3
virtualenv -p/usr/bin/python3 <venv>
The issue seems to rise from a missing ensurepip module. I fixed this by just downloading the Python 3.4 sources, unpacking them and copying the unpacked lib/ensurepip/ to /usr/lib/python3.4/ after which python3 -m venv seems to work fine.
What do you mean? virtualenv exists exactly so that your libs are installed in your local directory and not globally in the system. I'm not sure how it could result in broken mess in the system that way.
docker pull python:2.7
docker pull python:3
For more granular tags:
Either way you are hand installing a lot of packages.
I transitioned to 3 over a year ago and haven't looked back. I am happy with how the ecosystem has adapted and the direction Python is taking.
Type annotations, liberal use of and expansion of syntax for generators, language cleanup and additions to the standard library really make it another and better language.
Since I write a lot of sub 1000 line scripts for system admin tasks, it tends to not be worth forcing a Python 3 dependency just to make some small task easier.
Finally there are still a few really useful libraries that are python2 only (such as pysphere for vmware vSphere) and salt (saltstack) runs under the system python instance (py 2) that most code I write is still python 2.
Most of the code I write I try and write it so it should work on both, however without being tested and due to the nature of fairly quick development and limited testing, its almost certain there will be a few issues with running on Python 3.
Once they can convince Red Hat to replace the system python with python 3 (which will require some major work since I believe yum and a lot of other python code is not compatible), I think you will see a lot faster decline.
In either case, it's irrelevant