Earlier quoted context omitted.
Debian is its own worst enemy with things like this. It’s why we eventually moved off it at a previous job, because deploying Python server applications on it was dreadful. I’m sure it’s better if you’re deploying an appliance that you hand off and never touch again, but for evolving modern Python servers it’s not well suited.
Yes 1000x What is it with them which makes them feel entitled to have special "dist-packages" vs "site-packages" as is the default? This drives me nuts, when I have a bunch of native packages I want to bundle in our in-house python deployment. CentOS and Ubuntu are vanilla, and only Debian (mind-boggingly) deviates from the well-trodden path. I still haven't figured out how to beat this dragon. All suggestions welcom…
Ask HN: Is anyone using PyPy for real work?
31–40 of 185 posts
Re: Ask HN: Is anyone using PyPy for real work?
#32I use it for data transformation, cleanup and enrichment. (TXT, CSV, Json, XML, database) to (TXT, CSV, JSON, XML, database). Speed up of 30x - 40x. The highest speedup on those that require logic in the transformation. (lot of function calls, numerical operations and dictionary lookups).
Re: Ask HN: Is anyone using PyPy for real work?
#33We don't. To be honest, I didn't realize PyPy supported Python 3. I thought it was eternally stuck on Python 2.7. So the good: It apparently now supports Python 3.9? Might want to update your front page, it only mentions Python 3.7. The bad: It only supports Python 3.9, we use newer features throughout our code, so it'd be painful to even try it out.
Maybe the site is not up to date ?
Re: Ask HN: Is anyone using PyPy for real work?
#34I use CPython most of the time but PyPy was a real lifesaver when I was doing a project that bridged EMOF and RDF, particularly I was working with moderately sized RDF models (say 10 million triples) with rdflib. With CPython, I was frustrated with how slow it was, and complained about it to the people I was working with, PyPy was a simple upgrade that sped up my code to the point where it was comfortable to work wit…
Re: Ask HN: Is anyone using PyPy for real work?
#35Earlier quoted context omitted.
Debian is its own worst enemy with things like this. It’s why we eventually moved off it at a previous job, because deploying Python server applications on it was dreadful. I’m sure it’s better if you’re deploying an appliance that you hand off and never touch again, but for evolving modern Python servers it’s not well suited.
Yes 1000x What is it with them which makes them feel entitled to have special "dist-packages" vs "site-packages" as is the default? This drives me nuts, when I have a bunch of native packages I want to bundle in our in-house python deployment. CentOS and Ubuntu are vanilla, and only Debian (mind-boggingly) deviates from the well-trodden path. I still haven't figured out how to beat this dragon. All suggestions welcom…
Re: Ask HN: Is anyone using PyPy for real work?
#36We don't. To be honest, I didn't realize PyPy supported Python 3. I thought it was eternally stuck on Python 2.7. So the good: It apparently now supports Python 3.9? Might want to update your front page, it only mentions Python 3.7. The bad: It only supports Python 3.9, we use newer features throughout our code, so it'd be painful to even try it out.
Re: Ask HN: Is anyone using PyPy for real work?
#37We don't. To be honest, I didn't realize PyPy supported Python 3. I thought it was eternally stuck on Python 2.7. So the good: It apparently now supports Python 3.9? Might want to update your front page, it only mentions Python 3.7. The bad: It only supports Python 3.9, we use newer features throughout our code, so it'd be painful to even try it out.
Re: Ask HN: Is anyone using PyPy for real work?
#38I use PyPy quite often as a 'free' way to make some non-numpy CPU-bound Python script faster. This is also the context for when I bring up PyPy to others. The biggest blocker for me for 'defaulting' to PyPy is a) issues when dealing with CPython extensions and how quite often it ends up being a significant effort to 'port' more complex applications to PyPy b) the muscle memory for typing 'python3' instead of 'pypy3'.
For the b) part, you should consider creating alias for that command, if it really might lead for you to not use it otherwise.