11 ms·

Python 3.13.0 Is Released

268 points by Siecje 2y ago

mg 2y ago
When I'm in a docker container using the Python 3 version that comes with Debian - is there an easy way to swap it out for this version so I can test how my software behaves under 3.13?
- ebb_earl_co 2y ago
  This[0] is the Docker Python using Debian Bookworm, so as soon as 3.13.0 (not the release candidate I've linked to) is released, there will be an image. Otherwise, there's always the excellent `pyenv` to use, including this person's docker-pyenv project [1] [0] https://hub.docker.com/layers/library/python/3.13.0rc3-slim-bookworm/images/sha256-093961560ed6ad50276b4abe10431e24b1d3f713ff86d6b963bc3de853c07859?context=explore https://hub.docker.com/layers/library/python/3.13.0rc3-slim-... [1] https://github.com/tzenderman/docker-pyenv?tab=readme-ov-file https://github.com/tzenderman/docker-pyenv?tab=readme-ov-fil...
  - mg 2y ago
    Hmm.. I think this is a misunderstanding. What I meant is: While I am already inside a container running Debian, can I ... 1: ./myscript.py 2: some_magic_command 3: ./myscript.py So 1 runs it under 3.11 (which came with Debian) and 2 runs it under 3.13. I don't need to preserve 3.11. some_magic_command can wrack havoc in the container as much as it wants. As soon as I exit it, it will be gone anyhow. The in a sense, the question is not related to Docker at all. I just mentioned that I would do it inside a container to emphasize that I don't need to preserve anything.
    - kstrauser 2y ago
      The magic command in other settings would be pyenv. It lets you have as many different Python versions installed as you wish. Pro tip: outside Docker, don’t ever use the OS’s own Python if you can avoid it.
      - maleldil 2y ago
        > don’t ever use the OS’s own Python if you can avoid it. This includes Homebrew's Python installation, which will update by itself and break things.
        kstrauser 2y ago
        Yep. I only have Homebrew's Python installed because some other things in Homebrew depend on it. I use pyenv+virtualenv exclusively when developing my own code. (Technically, I use uv now, but to the same ends.)
      - cuu508 2y ago
        > Pro tip: outside Docker, don’t ever use the OS’s own Python if you can avoid it. Why not?
        kstrauser 2y ago
        It's unlikely that the OS's version of Python, and the Python packages available through the OS, are going to be the ones you'd install of your own volition. And on your workstation, it's likely you'll have multiple projects with different requirements. You almost always want to develop in a virtualenv so you can install the exact versions of things you need without conflicting with the ones the OS itself requires. If you're abstracting out the site-packages directory anyway, why not take one more step and abstract out Python, too? Things like pyenv and uv make that trivially easy. For instance, this creates a new project using Python 3.13. $ uv init -p python3.13 foo $ cd foo $ uv sync $ .venv/bin/python --version Python 3.13.0rc2 I did not have Python 3.13 installed before I ran those commands. Now I do. It's so trivially easy to have per-project versions that this is my default way of using Python. You can get 95% of the same functionality by installing pyenv and using it to install the various versions you might want. It's also an excellent tool. Python's own built-in venv module (https://docs.python.org/3/library/venv.html https://docs.python.org/3/library/venv.html) makes it easy to create virtualenvs anytime you want to use them. I like using uv to combine that and more into one single tool, but that's just my preference. There are many tools that support this workflow and I highly recommend you find one you like and use it. (But not pipenv. Don't pick that one.)
    - maleldil 2y ago
      You can use pyenv to create multiple virtual environments with different Python versions, so you'd run your script with (eg) venv311/bin/python and venv313/bin/python
    - orf 2y ago
      Ignore the talk below about pyenv, it’s not even slightly suitable for this task. You want precompiled Python binaries. Use “uv” for this, rather than hacking it together with pyenv.
      - kstrauser 2y ago
        Use either one. `pyenv install 3.x` is slower than `uv python install 3x`, but that's not the most common operation I use either of those tools for. Uv is also comparatively brand new, and while I like and use it, I'm sure plenty of shops aren't racing to switch to it. If you already have pyenv, use it. If you don't have pyenv or uv, install uv and use that. Either one is a huge upgrade over using the default Python from your OS.
        orf 2y ago
        This makes sense for a desktop environment, but for a disposable testing container there is no way that building and compiling each version of Python like that is a sensible use of time/resources.
        kstrauser 2y ago
        For that kind of thing I'd always either used the tagged Python images in Docker Hub or put the build step in an early layer that didn't have to re-run each time. One other advantage is that you know the provenance of the python executable when you build it yourself. Uv downloads a prebuilt exe from https://gregoryszorc.com/docs/python-build-standalone/main/ https://gregoryszorc.com/docs/python-build-standalone/main/ who is a very reputable, trusted source, but it's not the official version from python.org. If you have very strict security requirements, that may be something to consider. If you use an OS other than Linux/Mac/Windows on x86/ARM, you'll have to build your own version. If you want to use readline instead of libedit, you'll have to build your own version. I am personally fine with those limitations. All of the OSes I regularly use are covered. I'm satisfied with the indygreg source security. The libedit version works fine for me. I like that I can have a new Python version a couple seconds after asking for uv. There are still plenty of reasons why you might want to use pyenv to build it yourself.
- silveraxe93 2y ago
  Install `uv` then run `uv run --python 3.13 my_script.py`
rkwz 2y ago
> Free-threaded execution allows for full utilization of the available processing power by running threads in parallel on available CPU cores. While not all software will benefit from this automatically, programs designed with threading in mind will run faster on multi-core hardware. Would be nice to see performance improvements for libraries like FastAPI, NetworkX etc in future.
- v3ss0n 2y ago
  They are not threaded at all.
  - cr125rider 2y ago
    Correct. Async stuff in Python is based on libuv like event loops similar to how Nodejs and others operate, not full threads.
    - v3ss0n 2y ago
      Yeah, they have their own asyncio python runner
gjvc 2y ago
looking forward to the GraalVM version
pansa2 2y ago
Python versions 3.11, 3.12 and now 3.13 have contained far fewer additions to the language than earlier 3.x versions. Instead the newest releases have been focusing on implementation improvements - and in 3.13, the new REPL, experimental JIT & GIL-free options all sound great! The language itself is (more than) complex enough already - I hope this focus on implementation quality continues.
- formerly_proven 2y ago
  The last couple years also saw a stringent approach to deprecations: If something is marked as deprecated, it WILL be removed in a minor release sooner than later.
  - kstrauser 2y ago
    Yep. They’ve primarily (entirely?) involved removing ancient libraries from stdlib, usually with links to maintained 3rd party libraries. People who can’t/won’t upgrade to newer Pythons, perhaps because their old system that uses those old modules can’t run a newer one, aren’t affected. People using newer Pythons can replace those modules. There may be a person in the world panicking that they need to be on Python 3.13 and also need to parse Amiga IFF files, but it seems unlikely.
    - Doxin 2y ago
      I mean the stdlib is open source too, so you could always vendor deprecated stdlib modules. Most of them haven't changed in eons either so the lack of official support probably doesn't change much.
- csdreamer7 2y ago
  > The language itself is (more than) complex enough already - I hope this focus on implementation quality continues. As do I.
  - avidphantasm 2y ago
causal 2y ago
Any rule of thumb when it comes to adopting Python releases? Is it usually best to wait for the first patch version before using in production?
- instig007 2y ago
  Have a rubust CI and tests, and deploy as early as you can.
  - kstrauser 2y ago
    Yup. At my last gig, upgrading to a new version meant setting the Docker tag to the new one and running `make test`. If that passed, we were 99% certain it was safe for prod. The other 1% was covered by running in pre-prod for a couple days.
    - odie5533 2y ago
      This is the way.
- zenonu 2y ago
  I'm constrained by libraries with guaranteed version compatibility. Unless you're operating in NIH universe, I bet you are as well.
- user070223 2y ago
  When should you upgrade to Python 3.13? https://pythonspeed.com/articles/upgrade-python-3.13/ https://pythonspeed.com/articles/upgrade-python-3.13/ Python libraries support https://pyreadiness.org/3.13/ https://pyreadiness.org/3.13/
- oebs 2y ago
  We follow this rule (about two dozen services with in total ~100k loc of Python): By default, use the version 1 release below the latest. I.e. we currently run 3.11 and will now schedule work to upgrade to 3.12, which is expected to be more or less trivial for most services. The rationale is that some of the (direct and transitive) dependencies will take a while to be compatible with the latest release. And waiting roughly a year is both fast enough to not get too much behind, and slow enough to expect that most dependencies have caught up with the latest release.
ajay-d 2y ago
Still in prerelease (RC3), no? At least at time of writing
- pansa2 2y ago
  Yeah, the past tense on the What’s New page isn't (yet) accurate: > Python 3.13 was released on October 7, 2024
- milliams 2y ago
  It looks like it releases today (see https://peps.python.org/pep-0719/ https://peps.python.org/pep-0719/), but the release is not yet made on https://www.python.org/downloads/ https://www.python.org/downloads/ and the tag has not been made in Git yet.
  - pidjan 2y ago
    https://www.python.org/downloads/release/python-3130/ https://www.python.org/downloads/release/python-3130/
CJefferson 2y ago
Good to get advanced notice, if I read all the way down, that they will silently completely change the behavior of multiprocessing in 3.14 (only on Unix/Linux, in case other people wonder what’s going on), which is going to break a bunch of programs I work with. I really like using Python, but I can’t keep using it when they just keep breaking things like this. Most people don’t read all the release notes.
- icegreentea2 2y ago
  Not defending their specific course of action here, but you should probably try to wade into the linked discussion (https://github.com/python/cpython/issues/84559 https://github.com/python/cpython/issues/84559). Looks like the push to disable warnings (in 3.13) is mostly coming from one guy.
  - CJefferson 2y ago
    I think should have a dig. While it’s not perfect, I know a few other people people who do “set up lots of data structures, including in libraries, then make use of the fact multiprocessing uses fork to duplicate them”. While fork always has sharp edges, it’s also long been clearly documented that’s the behavior on Linux.
    - int_19h 2y ago
      I'm pretty sure that significantly more people were burned by fork being the default with no actual benefit to their code, whether because of the deadlocks etc that it triggers in multithreaded non-fork-aware code, or because their code wouldn't work correctly on other platform. Keeping it there as an option that one can explicitly enable for those few cases where it's actually useful and with full understanding of consequences is surely the better choice for something as high-level as Python.
      - CJefferson 2y ago
        I agree that fork was an awful default. However, changing the default silently just means people's code is going to change behaviour between versions, or silently break if someone with an older version runs their code. At this point, it's probably better to just require people give an explicit choice (they can even make one of the choice names be 'default' or something, to make life easy for people who don't really care).
stevesimmons 2y ago
And Azure Functions still doesn't support Python 3.12, released more than a year ago!
- cr125rider 2y ago
  We have switched to exclusively using Docker Images in Lambda on AWS cause their runtime team constantly breaks things and is behind with a bunch of releases.
- benrutter 2y ago
  It was similar last year when 3.12 came out and 3.11 still wasn't supported. I'm really curious what makes azure functions so slow to upgrade available run times, or if it's just that they figure demand for the latest python version isn't there.
- cozzyd 2y ago
  I wonder if FreeCAD supports 3.12 yet. Really annoying that FreeCAD got dropped from the latest Fedora due to breaking python changes...
SubiculumCode 2y ago
What I've been surprised about is the number of python packages that require specific python versions(e.g., works on 3.10, but not 3.11. Package versioning is already touchy enough without the language itself causing it in minor upgrades. And will python 3.14 be named pi-thon 3.14. I will see myself out.
- mixmastamyk 2y ago
  Also, Py2 ended approaching Euler’s number, 2.7.18.
- ericfrederich 2y ago
  Today someone's pipeline broke because they were using python:3 from Dockerhub and got an unexpected upgrade ;-) Specifically, pendulum hasn't released a wheel yet for 3.13 so it tried to build from source but it uses Rust and the Python docker image obviously doesn't have Rust installed.
wdroz 2y ago
With the 3.13 TypeIs[0] and the 3.10 TypeGuard[1], we can achieve some of Rust's power (such as the 'if let' pattern) without runtime guarantees. This is a win for the DX, but this is not yet widely used. For example, "TypeGuard[" appears in only 8k Python files on GitHub.[2] [0] -- https://docs.python.org/3.13/library/typing.html#typing.TypeIs https://docs.python.org/3.13/library/typing.html#typing.Type... [1] -- https://docs.python.org/3.13/library/typing.html#typing.TypeGuard https://docs.python.org/3.13/library/typing.html#typing.Type... [2] -- https://github.com/search?q=%22TypeGuard%5B%22+path%3A*.py&type=Code&ref=advsearch&l=&l= https://github.com/search?q=%22TypeGuard%5B%22+path%3A*.py&t...
- Buttons840 2y ago
  What type checker do you recommend?
  - Ey7NFZ3P0nzAe 2y ago
    Beartype is incredible. It is soo fast I put it as decorator on all functions of all my projects. It's day and night compared to typeguard. Also the dev is... Completely out of this world
    - HenriTEL 2y ago
      I don't get the point of a runtime type checker. It adds a lot of noise with those decorators everywhere and you need to call each section of the code to get full coverage, meaning 100% test coverage. At that point just use rust, or am I missing something?
      - Buttons840 2y ago
        It looks like you call a function near the beginning of your Python program / application that does all the type checking at startup time. IDK for sure, I haven't used the library. Someone using Python doesn't "just use Rust", there are very clear pros and cons and people already using Python are doing so for a reason. It is sometimes helpful to have type checks in Python though.
BiteCode_dev 2y ago
I still see Python 3.12.7 being the latest one, with 3.13 delayed because of the GC perf regression. The link, for me, points to the 3.13 RC. Am I seeing a cached version and you see 3.13 ? Cause I can't see it on the homage page download link either.
- fmajid 2y ago
  No, they jumped the gun.
boarush 2y ago
Python version from 3.10 have had a very annoying bug with the SSLContext (something related only to glibc) where there are memory leaks when opening new connections to new hosts and eventually causes any service (dockerized in my case) to crash due to OOM. Can still see that the issues have not been resolved in this release which basically makes it very difficult to deploy any production grade service difficult.
- infocollector 2y ago
  Can you please link me to a raised issue for this? This sounds concerning.
  - saurik 2y ago
    While this bug has been around longer than merely since 3.10, I am betting this is the one, based on the description of the issue: https://github.com/python/cpython/issues/84904 https://github.com/python/cpython/issues/84904 (Don't let the associates with asyncio throw you: that was merely the code in which it was first found; later code transcends it.)
    - boarush 2y ago
      not just this one, I've been tracking this too https://github.com/python/cpython/issues/109534 https://github.com/python/cpython/issues/109534
- orf 2y ago
  Maybe related to this segfault I found on MacOS? https://github.com/python/cpython/issues/114653 https://github.com/python/cpython/issues/114653
  - boarush 2y ago
    I've been tracking this one: https://github.com/python/cpython/issues/109534 https://github.com/python/cpython/issues/109534, but there are multiple others raised in the cpython repo over on Github. Searching for asyncio or sslcontext shows multiple issues raised over the years with no fix in place.
rhnamec 2y ago
[flagged]
- int_19h 2y ago
  If you're making claims about defamation and libel, at least be specific.
  - at_your_service 2y ago
    Discussion of one of the victims of the Steering Council: https://news.ycombinator.com/item?id=41625044 https://news.ycombinator.com/item?id=41625044 https://news.ycombinator.com/item?id=41625688 https://news.ycombinator.com/item?id=41625688
bun_terminator 2y ago
I appreciate the effort to leave out the "And now for something completely different" section (on https://www.python.org/downloads/release/python-3130/ https://www.python.org/downloads/release/python-3130/) after the previous drama.
lumpa 2y ago
I has officially been released: https://blog.python.org/2024/10/python-3130-final-released.html https://blog.python.org/2024/10/python-3130-final-released.h...
deleted 2y ago
[deleted]

268 points by Siecje 2y ago

mg 2y ago

When I'm in a docker container using the Python 3 version that comes with Debian - is there an easy way to swap it out for this version so I can test how my software behaves under 3.13?

ebb_earl_co 2y ago
This[0] is the Docker Python using Debian Bookworm, so as soon as 3.13.0 (not the release candidate I've linked to) is released, there will be an image. Otherwise, there's always the excellent `pyenv` to use, including this person's docker-pyenv project [1] [0] https://hub.docker.com/layers/library/python/3.13.0rc3-slim-bookworm/images/sha256-093961560ed6ad50276b4abe10431e24b1d3f713ff86d6b963bc3de853c07859?context=explore https://hub.docker.com/layers/library/python/3.13.0rc3-slim-... [1] https://github.com/tzenderman/docker-pyenv?tab=readme-ov-file https://github.com/tzenderman/docker-pyenv?tab=readme-ov-fil...
- mg 2y ago
  Hmm.. I think this is a misunderstanding. What I meant is: While I am already inside a container running Debian, can I ... 1: ./myscript.py 2: some_magic_command 3: ./myscript.py So 1 runs it under 3.11 (which came with Debian) and 2 runs it under 3.13. I don't need to preserve 3.11. some_magic_command can wrack havoc in the container as much as it wants. As soon as I exit it, it will be gone anyhow. The in a sense, the question is not related to Docker at all. I just mentioned that I would do it inside a container to emphasize that I don't need to preserve anything.
  - kstrauser 2y ago
    The magic command in other settings would be pyenv. It lets you have as many different Python versions installed as you wish. Pro tip: outside Docker, don’t ever use the OS’s own Python if you can avoid it.
    - maleldil 2y ago
      > don’t ever use the OS’s own Python if you can avoid it. This includes Homebrew's Python installation, which will update by itself and break things.
      - kstrauser 2y ago
        Yep. I only have Homebrew's Python installed because some other things in Homebrew depend on it. I use pyenv+virtualenv exclusively when developing my own code. (Technically, I use uv now, but to the same ends.)
    - cuu508 2y ago
      > Pro tip: outside Docker, don’t ever use the OS’s own Python if you can avoid it. Why not?
      - kstrauser 2y ago
        It's unlikely that the OS's version of Python, and the Python packages available through the OS, are going to be the ones you'd install of your own volition. And on your workstation, it's likely you'll have multiple projects with different requirements. You almost always want to develop in a virtualenv so you can install the exact versions of things you need without conflicting with the ones the OS itself requires. If you're abstracting out the site-packages directory anyway, why not take one more step and abstract out Python, too? Things like pyenv and uv make that trivially easy. For instance, this creates a new project using Python 3.13. $ uv init -p python3.13 foo $ cd foo $ uv sync $ .venv/bin/python --version Python 3.13.0rc2 I did not have Python 3.13 installed before I ran those commands. Now I do. It's so trivially easy to have per-project versions that this is my default way of using Python. You can get 95% of the same functionality by installing pyenv and using it to install the various versions you might want. It's also an excellent tool. Python's own built-in venv module (https://docs.python.org/3/library/venv.html https://docs.python.org/3/library/venv.html) makes it easy to create virtualenvs anytime you want to use them. I like using uv to combine that and more into one single tool, but that's just my preference. There are many tools that support this workflow and I highly recommend you find one you like and use it. (But not pipenv. Don't pick that one.)
  - maleldil 2y ago
    You can use pyenv to create multiple virtual environments with different Python versions, so you'd run your script with (eg) venv311/bin/python and venv313/bin/python
  - orf 2y ago
    Ignore the talk below about pyenv, it’s not even slightly suitable for this task. You want precompiled Python binaries. Use “uv” for this, rather than hacking it together with pyenv.
    - kstrauser 2y ago
      Use either one. `pyenv install 3.x` is slower than `uv python install 3x`, but that's not the most common operation I use either of those tools for. Uv is also comparatively brand new, and while I like and use it, I'm sure plenty of shops aren't racing to switch to it. If you already have pyenv, use it. If you don't have pyenv or uv, install uv and use that. Either one is a huge upgrade over using the default Python from your OS.
      - orf 2y ago
        This makes sense for a desktop environment, but for a disposable testing container there is no way that building and compiling each version of Python like that is a sensible use of time/resources.
        kstrauser 2y ago
        For that kind of thing I'd always either used the tagged Python images in Docker Hub or put the build step in an early layer that didn't have to re-run each time. One other advantage is that you know the provenance of the python executable when you build it yourself. Uv downloads a prebuilt exe from https://gregoryszorc.com/docs/python-build-standalone/main/ https://gregoryszorc.com/docs/python-build-standalone/main/ who is a very reputable, trusted source, but it's not the official version from python.org. If you have very strict security requirements, that may be something to consider. If you use an OS other than Linux/Mac/Windows on x86/ARM, you'll have to build your own version. If you want to use readline instead of libedit, you'll have to build your own version. I am personally fine with those limitations. All of the OSes I regularly use are covered. I'm satisfied with the indygreg source security. The libedit version works fine for me. I like that I can have a new Python version a couple seconds after asking for uv. There are still plenty of reasons why you might want to use pyenv to build it yourself.
silveraxe93 2y ago
Install `uv` then run `uv run --python 3.13 my_script.py`

rkwz 2y ago

> Free-threaded execution allows for full utilization of the available processing power by running threads in parallel on available CPU cores. While not all software will benefit from this automatically, programs designed with threading in mind will run faster on multi-core hardware. Would be nice to see performance improvements for libraries like FastAPI, NetworkX etc in future.

v3ss0n 2y ago
They are not threaded at all.
- cr125rider 2y ago
  Correct. Async stuff in Python is based on libuv like event loops similar to how Nodejs and others operate, not full threads.
  - v3ss0n 2y ago
    Yeah, they have their own asyncio python runner

gjvc 2y ago

looking forward to the GraalVM version

pansa2 2y ago

Python versions 3.11, 3.12 and now 3.13 have contained far fewer additions to the language than earlier 3.x versions. Instead the newest releases have been focusing on implementation improvements - and in 3.13, the new REPL, experimental JIT & GIL-free options all sound great! The language itself is (more than) complex enough already - I hope this focus on implementation quality continues.

formerly_proven 2y ago
The last couple years also saw a stringent approach to deprecations: If something is marked as deprecated, it WILL be removed in a minor release sooner than later.
- kstrauser 2y ago
  Yep. They’ve primarily (entirely?) involved removing ancient libraries from stdlib, usually with links to maintained 3rd party libraries. People who can’t/won’t upgrade to newer Pythons, perhaps because their old system that uses those old modules can’t run a newer one, aren’t affected. People using newer Pythons can replace those modules. There may be a person in the world panicking that they need to be on Python 3.13 and also need to parse Amiga IFF files, but it seems unlikely.
  - Doxin 2y ago
    I mean the stdlib is open source too, so you could always vendor deprecated stdlib modules. Most of them haven't changed in eons either so the lack of official support probably doesn't change much.
csdreamer7 2y ago
> The language itself is (more than) complex enough already - I hope this focus on implementation quality continues. As do I.
- avidphantasm 2y ago

causal 2y ago

Any rule of thumb when it comes to adopting Python releases? Is it usually best to wait for the first patch version before using in production?

instig007 2y ago
Have a rubust CI and tests, and deploy as early as you can.
- kstrauser 2y ago
  Yup. At my last gig, upgrading to a new version meant setting the Docker tag to the new one and running `make test`. If that passed, we were 99% certain it was safe for prod. The other 1% was covered by running in pre-prod for a couple days.
  - odie5533 2y ago
    This is the way.
zenonu 2y ago
I'm constrained by libraries with guaranteed version compatibility. Unless you're operating in NIH universe, I bet you are as well.
user070223 2y ago
When should you upgrade to Python 3.13? https://pythonspeed.com/articles/upgrade-python-3.13/ https://pythonspeed.com/articles/upgrade-python-3.13/ Python libraries support https://pyreadiness.org/3.13/ https://pyreadiness.org/3.13/
oebs 2y ago
We follow this rule (about two dozen services with in total ~100k loc of Python): By default, use the version 1 release below the latest. I.e. we currently run 3.11 and will now schedule work to upgrade to 3.12, which is expected to be more or less trivial for most services. The rationale is that some of the (direct and transitive) dependencies will take a while to be compatible with the latest release. And waiting roughly a year is both fast enough to not get too much behind, and slow enough to expect that most dependencies have caught up with the latest release.

ajay-d 2y ago

Still in prerelease (RC3), no? At least at time of writing

pansa2 2y ago
Yeah, the past tense on the What’s New page isn't (yet) accurate: > Python 3.13 was released on October 7, 2024
milliams 2y ago
It looks like it releases today (see https://peps.python.org/pep-0719/ https://peps.python.org/pep-0719/), but the release is not yet made on https://www.python.org/downloads/ https://www.python.org/downloads/ and the tag has not been made in Git yet.
- pidjan 2y ago
  https://www.python.org/downloads/release/python-3130/ https://www.python.org/downloads/release/python-3130/

CJefferson 2y ago

Good to get advanced notice, if I read all the way down, that they will silently completely change the behavior of multiprocessing in 3.14 (only on Unix/Linux, in case other people wonder what’s going on), which is going to break a bunch of programs I work with. I really like using Python, but I can’t keep using it when they just keep breaking things like this. Most people don’t read all the release notes.

icegreentea2 2y ago
Not defending their specific course of action here, but you should probably try to wade into the linked discussion (https://github.com/python/cpython/issues/84559 https://github.com/python/cpython/issues/84559). Looks like the push to disable warnings (in 3.13) is mostly coming from one guy.
- CJefferson 2y ago
  I think should have a dig. While it’s not perfect, I know a few other people people who do “set up lots of data structures, including in libraries, then make use of the fact multiprocessing uses fork to duplicate them”. While fork always has sharp edges, it’s also long been clearly documented that’s the behavior on Linux.
  - int_19h 2y ago
    I'm pretty sure that significantly more people were burned by fork being the default with no actual benefit to their code, whether because of the deadlocks etc that it triggers in multithreaded non-fork-aware code, or because their code wouldn't work correctly on other platform. Keeping it there as an option that one can explicitly enable for those few cases where it's actually useful and with full understanding of consequences is surely the better choice for something as high-level as Python.
    - CJefferson 2y ago
      I agree that fork was an awful default. However, changing the default silently just means people's code is going to change behaviour between versions, or silently break if someone with an older version runs their code. At this point, it's probably better to just require people give an explicit choice (they can even make one of the choice names be 'default' or something, to make life easy for people who don't really care).

stevesimmons 2y ago

And Azure Functions still doesn't support Python 3.12, released more than a year ago!

cr125rider 2y ago
We have switched to exclusively using Docker Images in Lambda on AWS cause their runtime team constantly breaks things and is behind with a bunch of releases.
benrutter 2y ago
It was similar last year when 3.12 came out and 3.11 still wasn't supported. I'm really curious what makes azure functions so slow to upgrade available run times, or if it's just that they figure demand for the latest python version isn't there.
cozzyd 2y ago
I wonder if FreeCAD supports 3.12 yet. Really annoying that FreeCAD got dropped from the latest Fedora due to breaking python changes...

SubiculumCode 2y ago

What I've been surprised about is the number of python packages that require specific python versions(e.g., works on 3.10, but not 3.11. Package versioning is already touchy enough without the language itself causing it in minor upgrades. And will python 3.14 be named pi-thon 3.14. I will see myself out.

mixmastamyk 2y ago
Also, Py2 ended approaching Euler’s number, 2.7.18.
ericfrederich 2y ago
Today someone's pipeline broke because they were using python:3 from Dockerhub and got an unexpected upgrade ;-) Specifically, pendulum hasn't released a wheel yet for 3.13 so it tried to build from source but it uses Rust and the Python docker image obviously doesn't have Rust installed.

wdroz 2y ago

With the 3.13 TypeIs[0] and the 3.10 TypeGuard[1], we can achieve some of Rust's power (such as the 'if let' pattern) without runtime guarantees. This is a win for the DX, but this is not yet widely used. For example, "TypeGuard[" appears in only 8k Python files on GitHub.[2] [0] -- https://docs.python.org/3.13/library/typing.html#typing.TypeIs https://docs.python.org/3.13/library/typing.html#typing.Type... [1] -- https://docs.python.org/3.13/library/typing.html#typing.TypeGuard https://docs.python.org/3.13/library/typing.html#typing.Type... [2] -- https://github.com/search?q=%22TypeGuard%5B%22+path%3A*.py&type=Code&ref=advsearch&l=&l= https://github.com/search?q=%22TypeGuard%5B%22+path%3A*.py&t...

Buttons840 2y ago
What type checker do you recommend?
- Ey7NFZ3P0nzAe 2y ago
  Beartype is incredible. It is soo fast I put it as decorator on all functions of all my projects. It's day and night compared to typeguard. Also the dev is... Completely out of this world
  - HenriTEL 2y ago
    I don't get the point of a runtime type checker. It adds a lot of noise with those decorators everywhere and you need to call each section of the code to get full coverage, meaning 100% test coverage. At that point just use rust, or am I missing something?
    - Buttons840 2y ago
      It looks like you call a function near the beginning of your Python program / application that does all the type checking at startup time. IDK for sure, I haven't used the library. Someone using Python doesn't "just use Rust", there are very clear pros and cons and people already using Python are doing so for a reason. It is sometimes helpful to have type checks in Python though.

BiteCode_dev 2y ago

I still see Python 3.12.7 being the latest one, with 3.13 delayed because of the GC perf regression. The link, for me, points to the 3.13 RC. Am I seeing a cached version and you see 3.13 ? Cause I can't see it on the homage page download link either.

fmajid 2y ago
No, they jumped the gun.

boarush 2y ago

Python version from 3.10 have had a very annoying bug with the SSLContext (something related only to glibc) where there are memory leaks when opening new connections to new hosts and eventually causes any service (dockerized in my case) to crash due to OOM. Can still see that the issues have not been resolved in this release which basically makes it very difficult to deploy any production grade service difficult.

infocollector 2y ago
Can you please link me to a raised issue for this? This sounds concerning.
- saurik 2y ago
  While this bug has been around longer than merely since 3.10, I am betting this is the one, based on the description of the issue: https://github.com/python/cpython/issues/84904 https://github.com/python/cpython/issues/84904 (Don't let the associates with asyncio throw you: that was merely the code in which it was first found; later code transcends it.)
  - boarush 2y ago
    not just this one, I've been tracking this too https://github.com/python/cpython/issues/109534 https://github.com/python/cpython/issues/109534
orf 2y ago
Maybe related to this segfault I found on MacOS? https://github.com/python/cpython/issues/114653 https://github.com/python/cpython/issues/114653
- boarush 2y ago
  I've been tracking this one: https://github.com/python/cpython/issues/109534 https://github.com/python/cpython/issues/109534, but there are multiple others raised in the cpython repo over on Github. Searching for asyncio or sslcontext shows multiple issues raised over the years with no fix in place.

rhnamec 2y ago

[flagged]

int_19h 2y ago
If you're making claims about defamation and libel, at least be specific.
- at_your_service 2y ago
  Discussion of one of the victims of the Steering Council: https://news.ycombinator.com/item?id=41625044 https://news.ycombinator.com/item?id=41625044 https://news.ycombinator.com/item?id=41625688 https://news.ycombinator.com/item?id=41625688

bun_terminator 2y ago

I appreciate the effort to leave out the "And now for something completely different" section (on https://www.python.org/downloads/release/python-3130/ https://www.python.org/downloads/release/python-3130/) after the previous drama.

lumpa 2y ago

I has officially been released: https://blog.python.org/2024/10/python-3130-final-released.html https://blog.python.org/2024/10/python-3130-final-released.h...

deleted 2y ago

[deleted]