Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python 3.13.0 Is Released

docs.python.org

Post reply on HN
Print view View original

61–70 of 135 posts

Re: Python 3.13.0 Is Released

#61

Post by saurik »

infocollector wrote: post #57
boarush wrote: post #54

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.

Can you please link me to a raised issue for this? This sounds concerning.

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

(Don't let the associates with asyncio throw you: that was merely the code in which it was first found; later code transcends it.)

Re: Python 3.13.0 Is Released

#62

Post by orf »

mg wrote: post #25
ebb_earl_co wrote: post #18

Earlier quoted context omitted.

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-... [1] https://github.com/tzenderman/docker-pyenv?tab=readme-ov-fil...

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,…

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.

Re: Python 3.13.0 Is Released

#63

Post by tightbookkeeper »

pkkm wrote: post #59
tightbookkeeper wrote: post #29

Earlier quoted context omitted.

Removing GIL only increases complexity.

It definitely does, but don't you think that it could be worth it if it makes multithreading usable for CPU-heavy tasks?

No. Python is orders of magnitude slower than even C# or Java. It’s doing hash table lookups per variable access. I would write a separate program to do the number crunching.

Everyone must now pay the mental cost of multithreading for the chance that you might want to optimize something.

Re: Python 3.13.0 Is Released

#64

Post by pidjan »

milliams wrote: post #8
ajay-d wrote: post #6

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

It looks like it releases today (see https://peps.python.org/pep-0719/ ), but the release is not yet made on https://www.python.org/downloads/ and the tag has not been made in Git yet.

https://www.python.org/downloads/release/python-3130/

Re: Python 3.13.0 Is Released

#65

Post by jnwatson »

oebs wrote: post #14
causal wrote: post #5

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?

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 r…

Yeah some deprecated C API stuff just got removed, so it might take me, a package maintainer, to catch up.

Re: Python 3.13.0 Is Released

#66

Post by int_19h »

the__alchemist wrote: post #36
pansa2 wrote: post #4

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.

I've love to see a revamp of the import system. It is a continuous source of pain points when I write Python. Circular imports all over unless I structure my program explicitly with this in mind. Using python path hacks with `sys` etc to go up a directory too.

The biggest problem with Python imports is that the resolution of non-relative module names always prioritizes local files, even when the import happens in stdlib. This means that, for any `foo` that is a module name in stdlib, having foo.py in your code can break arbitrary modules in stdlib. For example, this breaks:

   # bisect.py
   ...

   # main.py
   import random
with:

   Traceback (most recent call last):
     File ".../foo.py", line 1, in 
       import random
     File "/usr/lib/python3.12/random.py", line 62, in 
       from bisect import bisect as _bisect
   ImportError: cannot import name 'bisect' from 'bisect'
This is very frustrating because Python stdlib is still very large and so many meaningful names are effectively reserved. People are aware of things like "sys" or "json", but e.g. did you know that "wave", "cmd", and "grp" are also standard modules?

Worse yet is that these errors are not consistent. You might be inadvertently reusing an stdlib module name without even realizing it just because none of the stdlib (or third-party) modules that you import have it in their import graphs. Then you move on to a new version of Python or some of your dependencies, and suddenly it breaks because they have added an import somewhere.

But even if you are careful about checking every single module name against the list of standard modules, a new Python version can still break you by introducing a new stdlib module that happens to clash with one of yours. For example, Python 3.9 added "graphlib", which is a fairly generic name.

Re: Python 3.13.0 Is Released

#67

Post by int_19h »

tightbookkeeper wrote: post #63
pkkm wrote: post #59

Earlier quoted context omitted.

It definitely does, but don't you think that it could be worth it if it makes multithreading usable for CPU-heavy tasks?

No. Python is orders of magnitude slower than even C# or Java. It’s doing hash table lookups per variable access. I would write a separate program to do the number crunching. Everyone must now pay the mental cost of multithreading for the chance that you might want to optimize something.

Python doesn't do hash table lookups for local variable access. This only applies to globals and attributes of Python classes that don't use __slots__.

The mental cost of multithreading is there regardless because GIL is usually at the wrong granularity for data consistency. That is, it ensures that e.g. adding or deleting a single element to a dict happens atomically, but more often than not, you have a sequence of operations like that which need to be locked. In practice, in any scenario where your data is shared across threads, the only sane thing is to use explicit locks already.

Re: Python 3.13.0 Is Released

#68

Post by zbentley »

tightbookkeeper wrote: post #63
pkkm wrote: post #59

Earlier quoted context omitted.

It definitely does, but don't you think that it could be worth it if it makes multithreading usable for CPU-heavy tasks?

No. Python is orders of magnitude slower than even C# or Java. It’s doing hash table lookups per variable access. I would write a separate program to do the number crunching. Everyone must now pay the mental cost of multithreading for the chance that you might want to optimize something.

> It’s doing hash table lookups per variable access.

That hasn't been true for many variable accesses for a very long time. LOAD_FAST, LOAD_CONST, and (sometimes) LOAD_DEREF provide references to variables via pointer offset + chasing, often with caches in front to reduce struct instantiations as well. No hashing is performed. Those access mechanisms account for the vast majority (in my experience; feel free to check by "dis"ing code yourself) of Python code that isn't using locals()/globals()/eval()/exec() tricks. The remaining small minority I've seen is doing weird rebinding/shadowing stuff with e.g. closures and prebound exception captures.

https://github.com/python/cpython/blob/10094a533a947b72d01ed...

https://github.com/python/cpython/blob/10094a533a947b72d01ed...

So too for object field accesses; slotted classes significantly improve field lookup cost, though unlike LOAD_FAST users have to explicitly opt into slotting.

Don't get me wrong, there are some pretty regrettably ordinary behaviors that Python makes much slower than they need to be (per-binding method refcounting comes to mind, though I hear that's going to be improved). But the old saw of "everything is a dict in python, even variable lookups use hashing!" has been incorrect for years.

Re: Python 3.13.0 Is Released

#69

Post by Buttons840 »

wdroz wrote: post #28

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.Type... [1] -- https://docs.python.org/3.13/library/typing.html#typing.Type... […

What type checker do you recommend?

Re: Python 3.13.0 Is Released

#70

Post by int_19h »

CJefferson wrote: post #17
icegreentea2 wrote: post #16

Earlier quoted context omitted.

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 ). Looks like the push to disable warnings (in 3.13) is mostly coming from one guy.

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.

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.
Post reply on HN