not using it, but thank you for the work you put in, highly appreciated, we only strive, because so many of us put in the work :)
Ask HN: Is anyone using PyPy for real work?
121–130 of 185 posts
Re: Ask HN: Is anyone using PyPy for real work?
#122Earlier quoted context omitted.
You can try pip install pillow for a good example of how it works. I suspect there's a strong survivorship bias here, as you'd only notice the packages that don't ship with wheels.
Yeah, perhaps. One I remember from last year is the cryptography and numpy package, for instance. Now they do seem to ship with binary wheels, at least for my current Python and Linux version. Kerberos and Hadoop stuff obviously still doesn't, though. I guess the joke's on me for being stuck in this stack...
In order for a wheel to be used instead of a source distribution there needs to be one that matches your environment. For numpy you can take a look at the wheels for their latest release[1]. The filename of a wheel specifies where it can be used. Let's take an example:
numpy-1.25.2-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
This specifies cpython 3.9, linux, glibc 2.17 or higher, and x86_64 cpu. Looking through the list you will see that the oldest cpython supported is 3.9. So if you are running with an older version of python you will have to build from source.
I just learned a bit more about this recently because I could not figure out why PyQt6 would not install on my computer. It turned out my glibc was too old. Finally upgraded from Ubuntu 18.04.
Re: Ask HN: Is anyone using PyPy for real work?
#123Earlier quoted context omitted.
One should really consider using containers in this situation.
Can you describe what in this situation warrants it? I'm very curious about where the line is/should be.
In my experience leaving the system python interpreter the way it was shipped will save you enormous headaches down the road. Anytime I find myself needing additional python packages installed I will almost always at minimum create a virtual env, or ideally a container.
Re: Ask HN: Is anyone using PyPy for real work?
#124My biggest issue is that DataDog doesn’t support PyPy. Out of curiosity, I made a new branch of our app and took out DataDog and observed a significant improvement in performance when using PyPy vs CPython on the same branch (but can’t remember how much).
Do you mean the Python tracing library does not work out-of-the-box? disclaimer: I work there but not on the APM team
Correct. I think DD only supports CPython.
Re: Ask HN: Is anyone using PyPy for real work?
#125Years ago, yes I used it.
Nowadays, to be honest, everything that I need to be fast in Python is largely around numerical code which either calls out to C/C++ (via numpy or some ML library) or I use numba for. And these are either slower w/ PyPi or won't work.
HTTP web servers are notoriously slow in Python (even the fastest ones like falcon) but I found they either didn't play nicely with Pypi or weren't any faster. In large part because if the API does any kind of "heavy lifting" they can't be truly concurrent.
Re: Ask HN: Is anyone using PyPy for real work?
#126Earlier quoted context omitted.
Yep, I screw things up all the time with packages in homebrew that are written in python, when I forget to switch into a virtual env before doing stuff with pip. Debian's solution seems very sensible. And it is the same solution as homebrew, I suppose, as long as you don't interact with any of the homebrew-installed packages via pip. But I find it quite easy to accidentally do that.
export PIP_REQUIRE_VIRTUALENV=1 has been quite helpful in the past as pip then refuses to just install things directly.
There is https://peps.python.org/pep-0668/ which suggests that in the future this kind of behaviour will be default. I'm not sure of the specifics but I have seen lots of conversation about it in Debian circles.
Re: Ask HN: Is anyone using PyPy for real work?
#127Can you tell us the obstacles for incorporating learnings from or even backporting the work from PyPi back into CPython?
Re: Ask HN: Is anyone using PyPy for real work?
#128Earlier quoted context omitted.
Yep, I screw things up all the time with packages in homebrew that are written in python, when I forget to switch into a virtual env before doing stuff with pip. Debian's solution seems very sensible. And it is the same solution as homebrew, I suppose, as long as you don't interact with any of the homebrew-installed packages via pip. But I find it quite easy to accidentally do that.
export PIP_REQUIRE_VIRTUALENV=1 has been quite helpful in the past as pip then refuses to just install things directly.
Nice!
Re: Ask HN: Is anyone using PyPy for real work?
#129Can you tell us the obstacles for incorporating learnings from or even backporting the work from PyPi back into CPython?
There is significant cooperation between the two. When porting PyPy to a new Python version, we examine what changes CPython made. And CPython core developers are aware of PyPy. The main obstacle is developer time. CPython has to be very careful about backward compatibility, which includes not making the interpreter slower for a few while faster for many.
Re: Ask HN: Is anyone using PyPy for real work?
#130What is the compatibility of PyPy with a typical web server deployment? I am currently looking at testing compatibility with Tornado -> SQL Alchemy -> psycopg2. It seems like the C-extensions are a common tripping point. I see the recommendation to use psycopg2cffi, but it seems that package's last release was 2019 :(
SQL Alchemy actually points to PyPy in its recommendations of things to try in ORM performance. https://docs.sqlalchemy.org/en/20/faq/performance.html#resul...