Python 3.12 support

[reuvenstr]

I tried to find any information about it, but didn’t succeed. Can you please tell if there will be pypy support, or if there is already answers to it, just send me there 😃

thanks ahead

[mattip]

We are working on support for python 3.11 now. What feature of python 3.12 interests you?

[reuvenstr]

Its less features dependent upgrade that I’m looking for. More EOL upgrade to be always up to date. There are timelines for 3.11? Or do date?

[dgutson]

We are working on support for python 3.11 now. What feature of python 3.12 interests you?

Some annotations like @override for example

[mattip]

There are no timelines, this is a volunteer run project. Code contributions to close open issues or fiscal contributions are welcome.

[reuvenstr]

So i can just open issues and take something, if i can help?

[mattip]

Sure. Maybe start with the ones marked for the next release milestones or the 3.11 milestones

[gh-andre]

@mattip Thank you for PyPy - it does wonders speeding up @property constructs, etc, that slow down native Python a lot.

We are working on support for python 3.11 now. What feature of python 3.12 interests you?

I had this same question and wanted to mention another reason for having to use Python 3.12, which comes with Ubuntu 24.04. That is, Ubuntu 22.04 has Python 3.10 in their standard package repositories and Ubuntu 24.04 has Python 3.12. This makes deployments quite more straightforward in that one just needs to pull standard packages and then use PyPy only for those virtualenv environments that need extra performance.

For Windows it is less relevant, but standard Python releases no longer even offer prepackaged Windows installers for any version below Python 3.12.

[mattip]

Thanks for the comments. I am not sure installation is a convincing reason to keep tracking CPython releases. The site packages are not shared between CPython and PyPy: each interpreter manages its own set of packages. Ubuntu has pypy3 in its standard package repositories and we also provide portable builds for windows, macOS, linux-x86_64, linux_x86_32, and linux-aarch at https://downloads.python.org/pypy/

[gh-andre]

It's not so much sharing between repositories, as it is the fact that PyPy would be, say, Python 3.11 and the default system apt repository would have Python 3.12. What I did in the past is to install various version benders, like Conda or the one AWS uses for their Docker images (the name escapes me now), and it causes various problems between apps that know to run from 3.11 virtual environments and those that use the default Python 3.12.

I hear you that specific Ubuntu and other environments are not good enough of a reason. I guess what I'm trying to say is that if Python releases a new minor version each year, then it might be worth considering for PyPy releases that upgrade the Python version to skip every other Python version.

[SidPad03]

Just checking in to see if there have been any updates on PyPy’s support for Python 3.12. I understand that the team is currently focused on Python 3.11, but I wanted to express continued interest in 3.12 support. Any information on progress or timelines would be greatly appreciated.

[mattip]

I wanted to express continued interest in 3.12 support.

Why? What interests you in PyPy and/or Python3.12? We get very little feedback from users and what they use PyPy for.
We basically had decided to stop with Python3.10, but then a volunteer contributed 80% of what was needed to make a Python 3.11, so went ahead and did the other 80% needed for a release.
Would you or someone else you know be willing to do the work to get a Python 3.12?

[Rubyer77]

I use pypy for speed however in 3.11 you have to use f-strings like this:

f"Employee: {employee['name']}"

when in 3.12 you can use only single-quotes like this:

f'Employee: {employee['name']}'

and my codebase is full of the 3.12 version f'Employee: {employee['name']}' so it's annoying to change them all back to the ugly old version f"Employee: {employee['name']}" to use pypy 3.11.

[silverwind]

Yes, flexible f-strings (https://peps.python.org/pep-0701/) is the main reason I'm looking forward to 3.12.

[BarrensZeppelin]

I have a branch of PyPy 3.11 that almost supports Py3.12 f-strings - I just (🙃) need to fix some compile errors.

[cfbolz]

Amazing! If there is anything that I can help with, please let me know, I'm happy to take a look! Where's your branch?

[BarrensZeppelin]

It's here: https://github.com/BarrensZeppelin/pypy/commits/py3.11-pep-701-f-strings/
Unfortunately, I've been too busy to work on it for a while, but it's still on my todo-list.

[gh-andre]

@mattip

Why? What interests you in PyPy and/or Python3.12?

Python 3.12 is the default version on Ubuntu v24.04, which means there is no need to install version benders, like Conda, etc., which all are not ideal, to say the least. Using the default version of Python makes it very straightforward to deploy performance-oriented services via PyPy and regular ones using just the base CPython.

As far as Python syntax is concerned, v3.12 introduces type parameter lists, which makes it easier to maintain generics and also aligns Python more with other templated languages, like TypeScript and C++, so it'd nice to start using this syntax, but without PyPy support on Ubuntu 24.04, I cannot even go to Python 3.11 and just keep running PyPy 3.10, which is the default version of CPython on Ubuntu 22.04.

[ezntek]

TL;DR: Thank you PyPy people, you have done enough. To me at least, Python3.12's new features don't at all make a difference.

Typed parameter lists and nicer f-strings are certainly nice features, but from what I've been hearing from my peers and looking at this GitHub, PyPy has been quite...quiet.

Even I was surprised that you all (the PyPy team) even bothered to support 3.11... That release didn't even add that many features (from what I'm seeing on the web, its mostly just CPython speed improvements along with some minor stdlib tweaks, along with minor QOL features).

I don't even see what 3.12 could offer. The typing improvements may be a great benefit to people, but just to put this out there, Python type checkers are still absolutely horrible. I use Pyright, it's fine but for me, it didn't even report half the errors and issues I faced in a massive refactor of my main Python project. You can't even unwrap an optional type (MyType | None) properly, you need to rely on gaslighting the typechecker by creating a whole new variable, like so:

value_unwrapped: MyType = value  # type: ignore

Stuff like isinstance checks for "sum types" are still really poorly detected, half the time the type checker throws me errors as if I didn't already assert that this value is of this type. Please also keep in mind that the Python interpreter effectively throws all type annotations straight out the window, before running your code. This is valid:

def function(x: int) -> None:
    print(x + 5)
    return 4

assert function("definitely an integer!") == None

...until the bug is caught during runtime. I'm sorry, but I genuinely do not see why you all need generics and stuff to beautifully describe your types, when in reality, the Python type checker barely even gives a damn about you returning an integer from a function you mark as not returning anything.

As for me, I wrote an interpreter in Python. Originally, it was just for me to learn how to write a parser, but the project spiralled. It implements this wack language called IGCSE Pseudocode. Essentially, IGCSE is a secondary school curriculum made by the Cambridge people, and for their computer science course for 14-16 year olds, they made a wack programming language called Pseudocode that is so strict on syntax that you can write a parser for it, and not have real issues. No official runtime exists, because it isn't supposed to be a real programming language, only something students write with a pen on paper on exams, to make examiners' lives easier, so that they don't have to learn Python. Students in most schools teach Python in parallel to Pseudocode, so that students get a taste of real programming, which implies that most students have a Python interpreter to run code with. My interpreter (beancode) is written in Python (without any external dependencies) so that students can run IGCSE Pseudocode on their computers, to see what their weird exam language actually does, as well as being able to debug it.

I target Python 3.10 as a baseline, because our school standardizes on the Thonny IDE, which bundles Python 3.10 on darwin (our computer labs have iMacs). Coincidentally, when PyPy only supported 3.10, I made sure to test with it exclusively, so that eventually, enthusiasts in my school could grab PyPy to see beancode go faster, along with their own projects. For me, PyPy gives me consistent 4-7x speed boosts by me doing...nothing. I can even see the JIT warming up in benchmarks, which is quite cool to watch. Big kudos to you (all, the PyPy team) for writing such cool software, and feeding my impatience :) I also tutor people computer science to my peers as a student, PyPy is a very cool way to visualize JITs, and a good case study as to the benefits of them.

I almost never use any features in >=Python 3.11, just because they are so niche.

For y'all Python devs, I advise you to just target lower Python versions when you write code, who knows how new your Python will be. It obviously depends on what type of software you are writing, though. Writing F-strings the old way isn't even that bad, and I think that it's better than pestering these poor devs that (I presume, aren't paid much) with Python 3.12 support. Like Apple, I don't even know what's going on behind the CPython peoples' doors. Their new releases only have miniscule new features that make the same old Python (a very horribly slow programming language if you care even a little about performance) just a smidge faster, yet these bigger and more beautiful numbers seem to appeal to all of you so much...for no reason.

If you are writing massive humongous projects in Python, you either have your own problem, or you're using the wrong tool for the job (like me, even! Ideally, I wouldn't have written this interpreter in Python).

Python was always meant to be a toyish scripting language whereby you can write whatever you think, and your code will work, even if it is absolutely horrible. Your types don't matter; this fact costed me hours and days of headaches just refactoring. Set your Python version to 3.11 in Pyright, and see all your problems go away. If you really need to refactor your f-strings, I introduce you to sed. I'm sure you can do it. Use the right tools for the right job, if your Python has to go fast, target 3.11.