81–90 of 92 posts
Earlier quoted context omitted.
Convincing distros to package it as the default "python" should be the priority. Until that happens, Python 3 will see limited adoption. The path of least resistance will always have the most traffic.
It's a chicken and egg problem. So long as most Python libraries run on Python 2 but not Python 3, distros are going to package Python 2.
I think the case for Python begins to deteriorate as the project grows in complexity, and performance begins to matter greatly. PyPy is competing in this regard with Julia and Nimrod.
"Languages like C++ are not the solution, and dynamic languages end up disappointing when you grow past single programmer code. Isn't there a middle ground? There is: instead of patching an old decrepit corpse, start from zero using what you have learned. Start using the Nimrod programming language, which would look like this for the previous examples:"
import uri, strutils
proc shortestURL(urls: seq[TUrl]): TUrl =
if urls.len ꝉ https://gradha.github.io/articles/2014/03/the-sweet-trap-of-...
Earlier quoted context omitted.
It's a chicken and egg problem. So long as most Python libraries run on Python 2 but not Python 3, distros are going to package Python 2.
Actually, the majority of PyPI packages are python-3 compatible. For a status overview, see http://python3wos.appspot.com/
For my PyCon Russia talk, I pulled down the data for all 44,402 packages (as of May 31). 13.5% of all packages on PyPI support some version of Python 3. 75.5% of the top 200 packages by download count claim to support some Python 3 version (according to their setup.py classifiers). Additionally, 64% of the top 500 support some Python 3 version.
Another interesting thing I saw was that of those 44K packages, 44% of them have seen a release within the last 12 months (representing 82% of the last month's download share), and 22% of those packages released in the last year support some version of Python 3.
Earlier quoted context omitted.
Looks like they're over 80% of the way to hitting the funding goal for that one too: http://pypy.org/numpydonate.html
The problem is: even if numpy gets ported we still don't have scipy and a million other packages which require C bindings.
I created a simple Terminal instance that compares Python and PyPy in a performance test: https://terminal.com/tiny/shkhWWkcEV (this lets you compare the performance on a real Linux system, without installing anything)
Earlier quoted context omitted.
On a silly piece of code that nobody would ever have any use for. I have tried PyPy for "real" data and numerical tasks from time to time, and never have I noticed any sort of speedup. Usually it's slower than CPython. Perhaps this latest version will be different, who knows.
I'm using it in production, and speedups tend to be on the order of 4-5x for my app (the compute-intensive part involves hierarchical agglomerative clustering of documents by text similarity, so it's data/numbers-heavy). Obviously it'll depend on your individual application (and non-CPU-bound tasks won't benefit much), but we switched to PyPy because it showed major improvements in profiling of our app on production…
Earlier quoted context omitted.
Convincing distros to package it as the default "python" should be the priority. Until that happens, Python 3 will see limited adoption. The path of least resistance will always have the most traffic.
It's a chicken and egg problem. So long as most Python libraries run on Python 2 but not Python 3, distros are going to package Python 2.
The groundwork is done, and I think everyone who is going to support Py 3 without any extra prodding has already done so. Now we need the distros to come through and give that extra nudge to the maintainers that are still slacking, or encourage people to replace those libraries that refuse to update.