Maybe it would have been great to just say "python3 will be based on pypy"..
Definitely could use a another killer feature or two.
[deleted]
Making Python 3 more attractive
111–120 of 172 posts
Re: Making Python 3 more attractive
#112Re: Making Python 3 more attractive
#113The way to make Python 3 more attractive is to backport the best bits to Python 2.8...
I want Python 2.8. This is Python 2.7, but is based on PyPy (so it's waaay faster), and has requests + gevent + lxml built-in, and adds some small niceties from 3.x (yield from, a, b* = foo()).
Feel free to implement that in Pypy right now?
Re: Making Python 3 more attractive
#114Reasons I am excited about Python 3: * "yield from" * Unicode support (I'm German and the clear distinction between bytes and unicode really makes my life easier) * function annotations (PyCharm interprets them and uses them for static type checking) * cleaned up stdlib (not only names, but also features) * asyncio Library support is very good nowadays, pretty much all of the important libraries are either ported to…
Most of this stuff is great and I'm actually looking forward to moving to py3k. But I've been looking forward for a few years now, though, and it seems like that will continue to for a while longer. The main problem for me remains dependencies. Python makes it so easy to integrate stuff via pip/easy_install, but that's a double edged sword in this case: Since there's such a huge abundance of great libraries for anyth…
Depends on your requirements on code/performance, but in one of my projects I've been gradually switching over to python 3 (actually, moving old stuff over from 2) by using this module:
https://pypi.python.org/pypi/python-bond
It spawns a second python process that you can call/execute code from almost invisibly, first-class exceptions included. The main difference with other similar solutions is that it support call backs: a remote function can call back new code, and can do it so recursively.
You can intertwine old code and new one.
The main drawback is that it's not efficient for small/lightweight functions.
Re: Making Python 3 more attractive
#115I think the obsession with the GIL is sort of missing the point - people on python2 live with the GIL and don't really miss it, I don't think that's really the killer feature to drive python3 adoption. Especially considering its almost impossible to do without breaking something (most likely C extensions) and when you see the wailing and gnashing of teeth that came from python3 forcing people to fix their text encodings it doesn't look seem like more breaking changes are going to drive python3 further. What's more, python already has quite convenient multiprocessing, and python3 concurrent.futures makes it even easier - frankly I think too many people complain about the GIL without having tried multiprocessing (doesn't help that it seems every tutorial starts with multithreading, then tells you it doesn't really work, and only then tells you about multiprocessing). You only get to complain if that doesn't work for you!
Personally I think the driver is going to turn out to be type annotations. When you see the enthusiasm for adding type annotations to JS (typescript, ES6, etc) its easy to see that translating to python. Static analyzers can be a huge help (you can already get a taste of it with PyCharm) and I for one would like to move away from "traceback driven development" where you just have to keep re-running the code until all the preventable glitches are worked out...
Re: Making Python 3 more attractive
#116Earlier quoted context omitted.
> Yeah, I don't like the busywork that Pep8 makes me do it, and it's a lot, and some of it is stupid, but it has to be done Actually no, it hasn't. PEP8 is just a formatting standard, your code will work with your own standard too.
True, I meant this https://pypi.python.org/pypi/pep8
Guido doesn't like that tool; they're guidelines, not rules.
Re: Making Python 3 more attractive
#117Reasons I am excited about Python 3: * "yield from" * Unicode support (I'm German and the clear distinction between bytes and unicode really makes my life easier) * function annotations (PyCharm interprets them and uses them for static type checking) * cleaned up stdlib (not only names, but also features) * asyncio Library support is very good nowadays, pretty much all of the important libraries are either ported to…
So far I've focused on making new projects both Python 2 and 3 compatible, but "new stuff" in Python 3 is not always available when: - Laptop running Ubuntu Trusty: Python 3.4 - Production servers with Debian Wheezy: Python 3.2 - Laptop running Fedora 20: 3.3.2 You don't usually install Python in Linux using upstream, you install the version provided by your distribution and unfortunately Python 3 has differences bet…
You can install the binaries with a Virtualenv (at least on 2.X, virtualenv on 3.x is a pain until 3.4)
Re: Making Python 3 more attractive
#118Python developers would almost all upgrade in a single minute for 30%+ better performance. It's interesting that performance wasn't a topic at this rump session as reported; I moved over to Go about a year ago, and while I miss Python's expressivity at least once a week, I'm just not willing to slow down all my programs by 5x. On the other hand, if Python could double in speed, I'd likely try to rework it into our wo…
>Python developers would almost all upgrade in a single minute for 30%+ better performance. But strangely they don't - PyPy has hardly gained traction (albeit the python2->python3 switch didn't help) and looking at the benchmarks that's more like 5-7x performance. I suspect that most often, in places where performance matters enough in a way that would warranted refactoring a code-base from cpython to PyPy, they alre…
I want to use PyPy, and I have used it for a biggish server-based project I've been a part of.
The issue I've usually had with it is just small things – maybe an module we depend on doesn't work with PyPy yet, maybe PyPy3 isn't 3.3-compatible yet and can't use "yield from", which we use in our code or which our libraries use.
Dealing with those sort of small issues (and/or waiting for PyPy to fix them), worrying about whether the project I'm currently working on can use PyPy or if I need to use CPython instead, etc makes me stop worrying about trying to use it after a while. In my dev environment at least.
I do really love what the PyPy guys are doing though, and when it works it works damn well. Building it from source is also super pretty.
Re: Making Python 3 more attractive
#119Python developers would almost all upgrade in a single minute for 30%+ better performance. It's interesting that performance wasn't a topic at this rump session as reported; I moved over to Go about a year ago, and while I miss Python's expressivity at least once a week, I'm just not willing to slow down all my programs by 5x. On the other hand, if Python could double in speed, I'd likely try to rework it into our wo…
Have you tried Nim[rod]? Seems to be pythonesque in almost every way, except speed, in which it is goesque.
Aside from having whitespace-sensitive syntax, Nim isn't Python-esque at all. Nim very much encourages TIMTOWTDI over Python's there-should-be-preferably-one-way-to-do-it. Nim also has extremely flexible syntax where Python is rigid. See Nim's pervasive use of metaprogramming via macros, or its inclusion of user-defined symbolic operators (as per Haskell and Scala), or the fact that it considers `foo` and `Foo` and `FOO` and `f_O__o` to be equivalent identifiers, or its inclusion of UFCS.
Nim is a neat language, but comparisons to Python solely because it has semantic indentation are completely shallow (especially so when you consider that Guido doesn't even think that whitespace sensitivity is an important feature).
Re: Making Python 3 more attractive
#120These articles that assert low take up of Python never quantify in any scientific way why they think there is low take up of Python 3.
It's opinion presented as fact that Python 3 has low take up.
Without tangible proof I call bullshit.