PyPy has been working for me for several years now
utcc.utoronto.ca
utcc.utoronto.ca
Naming things is hard but it would be nice if people tried a bit harder to avoid clashes at least within the same ecosystem.
[edit]: After some searching, I notice that PEP 301 is actually dated Oct 2002, so perhaps I'm wrong. The public/advertised name was Cheese Shop for quite some time after that, but apparently the name PyPi was at least suggested much earlier than I thought.
This is why python has wheels.
So wheel is to cheese, as loaf is to bread.
https://www.chucklingcheese.co.uk/news/cheese-gift-guides/wh...
https://dustingram.com/talks/2018/10/23/inside-the-cheesesho... (halfway through)
PyPI is sometimes called the Cheeseshop.
This is a reference to this Monty Python skit, where a man goes into a cheeseshop which has no cheese for sale.
The joke is that when PyPI was first created, there was nothing in it. Hence, "The Cheeseshop".
But it does have stuff in it now, so it's not really even appropriate to call it that anymore.
Addendum: Every time I tried to understand Python packaging, I would come across the term "wheel" and my eyes would glaze over because I couldn't figure out what it was from context ("what the heck is a wheel?"). Maybe now I'll go back and finally understand Python packaging.
People having fun naming their projects with references or puns or whatever might make them more likely to make the project to begin with, which is probably more important. But even within Python, it's much easier for me to remember "ok, I need install numpy and requests," than "ok I need Beautiful Soup and Twist" or whatever.
that's 1 unit of a production of cheese is called a wheel.
On the other hand the memory footprint can be painful - not just the deferred garbage collection of things like weakrefs and closed files, but even regular objects. A while back I had hope that the faster cpython project would somewhat remove our need to use it, just so we could have a lower memory footprint, but that seems to have stalled
This is precisely where my attempt to use Pypy failed.
It is hot garbage for almost anything that isn't math though - which is okay, because it's been focused math from the start - strings and parsing an unstructured input is an exercise in pain for example. And the ecosystem is heavily geared toward math and scientific computing, so you will find yourself rolling your own stuff quite often if you deviate from that niche
How?
during array creation you can specify custom lower bound.
It basically had to go through Fortran -> C -> C++ (with pybind11) -> Python. At one point we had a slightly simpler setup with Fortran -> C -> Python (with ctypes), but ended up going with pybind11 after some discussion with the SciPy folks who steered us away from ctypes.
anyone who's ever used numpy/scipy has been using python integrated with fortran.
The main reason fortran is still used around is fundamentally LAPACK. BLAS has long been converted to C/Assembly, openblas mkl or others. But Lapack is a lot of code to translate not because fortran is better but the original authors wrote it in F77
I don't think backwards compatibility can really be the reason. Python does not care that much about backwards compatibility, as seen from the extensive list of features they remove in every release:
PyPy is a different, non-PSF implementation of Python
I think, that the first goal of PyPy was to compile Python to C or something like that. JIT came later.
You just for some reason decided to use the fact that the project was renamed at some point to fight a stupid battle on the Internetes.
Are you sure you understand the comment you are replying to? Your replies makes less and less sense. They just look like an attempt to pick a stupid fight.
If this needs repeating: I didn't deny that the project has a JIT compiler. I denied it was it's main goal. What you quoted confirms what I claim, but you seem to be misunderstanding this quote too?
"One of the not so secret goals of Armin Rigo, one of the PyPy founders, was to use PyPy together with some advanced partial evaluation magic sauce to somehow automatically generate a JIT compiler from the interpreter."
He is saying one of the founder's original goals was to automatically generate a JIT. It may not be the "main" goal but it is certainly one of the original goals per this quote.
If you want your code to run faster, you should probably just use PyPy.There are already languages that are more suited for that kind of model, that have a long history of incremental improvement of JIT compiler design and implementation. Why is Python trying to compete in the field where it's almost certainly guaranteed to lose, and is almost certainly guaranteed to win nothing?
Having an interpreter is great for some things. Especially, if you want to have bindings to third-party libraries, which is something Python does a lot.
----
My interpretation of the events is very different from yours. I believe that Python became swarmed by people who really, really want Java, but they feel that Java isn't cool for some superficial reason. And guided by the fear of crowd opinion, they won't just use Java and be content with it. Instead, they slowly make what used to be cool into a very bad clone of Java.
And the reason why the big names you mentioned have anything to do with JIT development is because they want to ride this wave of insecure and self-doubting developers to score popularity points, and, eventually, to control the popular technology. Esp. in the case of Microsoft, it's a multi-prong offensive. They've installed their people in Python Foundation, various SIGs related to Python. They've made CPython builds and CI run on their infrastructure, preventing it from choosing free tools for their development process... Microsoft has a bad rep with people who used to like Python, and that's why they don't rebrand it into MS-Python, but really, if they wanted to, they could certainly do it.
No matter how things are supposed to be, that is not how bootcamp, self called "engineers", do their programming.
Also as proven by other ecosystems, with JIT, AOT, REPLs, in the box, having an interpreter like CPython isn't a requirement for anything.
As for your MS jab, it was called IronPython.
It always seemed to me like it a "free" way to make it faster. Why would it matter whether it was endorsed by the BDFL or PSF?
If you want your code to run faster, you should probably just use PyPy.
Edit: things seem to have changed since I last looked into compiling a dependency for pypy. https://doc.pypy.org/en/latest/faq.html#do-c-extension-modul... now says they support c-extension modules without modifications
The package you mentioned, some postgres thing apparently, mentions they support pypy 3.9 and 3.10: https://www.psycopg.org/psycopg3/docs/basic/install.html
But maybe even with that, it's unable to support some extensions?
I remember it fondly. At the time, you could find the devs on freenode and the few times I bumped into something being slower than expected they jumped on my informal bug reports and quickly recreated it and fixed it etc. Awesome! :)
This was very confusing, especially because they mentionned pipx, which seems related to PyPi, so it was plausible this was about PyPi.
It could have been worse. Years ago a promising audio format was competing with mp3. It was better quality at any given compression and open source. The creators named it "Ogg Vorbis". Like some kind of dungeons and dragons character or something. I haven't seen it around for a long time, I think that's because the name was so stupid.
The format for audio files doesn't matter much nowadays, especially with sufficient bandwidth and most people streaming them from whatever service that uses whatever it will. In the era of Napster, those early 2000s, the formats were very front-of-mind.
Spotify is using it in their standalone clients.
uv + pyproject.toml + pyenv virtualenvs work pretty flawlessly got me.
> an experimental restricted-Python to C++ programming language compiler
Not by those that cannot phantom anything besides what is available today running in front of them.
Android versus Longhorn, as another example.
>Your request cannot be satisfied.
>You appear to be trying to break this web server. Goodbye.
Sorry, I guess...
Now with ruff and uv, much less.