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

91–100 of 135 posts

Re: Python 3.13.0 Is Released

#91

Post by Ey7NFZ3P0nzAe »

Buttons840 wrote: post #69
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?

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

Re: Python 3.13.0 Is Released

#92

Post by wdroz »

Buttons840 wrote: post #69
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?

disclaimer: I don't work on big codebases.

Pylance with pyright[0] while developing (with strict mode) and mypy[1] with pre-commit and CI.

Previously, I had to rely on pyright in pre-commit and CI for a while because mypy didn’t support PEP 695 until its 1.11 release in July.

[0] -- https://github.com/microsoft/pyright

[1] -- https://github.com/python/mypy

Re: Python 3.13.0 Is Released

#93

Post by pjmlp »

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.

Using Python on and off since version 1.6, I always like to point out that the language + standard library is quite complex, even more when taking into account all the variations across versions.

Looking forward to JIT maturing from now onwards.

Re: Python 3.13.0 Is Released

#94

Post by kstrauser »

tightbookkeeper wrote: post #88
kstrauser wrote: post #84

Earlier quoted context omitted.

Pretend for a second that I'm in a setting where: 1. The whole system is dedicated to running my one program, 2. I want to use multi threading to share large amounts of state between workers because that's appropriate to my specific use case, and 3. A 2-8x speedup without having to re-write parts of the code in another language would be fan-freaking-tastic. In other worse, I know what I'm doing, I've been doing this…

You can imagine that situation. But all python code is now impacted to support that case. Having a “python only” ecosystem makes about as much sense as a “bash only” ecosystem. Your tech stack includes much more. > In other worse, I know what I'm doing, I've been doing this since the 90s ditto. So that’s not relevant.

Sounds like a lot of speculation on your end because we don't have lots of evidence about how much this will affect anything, because until just now it's not been possible to get that information.

> ditto. So that’s not relevant.

Then I'm genuinely surprised you've never once stumbled across one of the many, many use cases where multithreaded CPU-intensive code would be a nice, obvious solution to a problem. You seem to think these are hypothetical and my experience has been that these are very real.

Re: Python 3.13.0 Is Released

#95

Post by pkkm »

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.

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

I'm assuming that by "everyone" you mean everyone who works on the Python implementation's C code? Because I don't see how that makes sense if you mean Python programmers in general. As far as I know, things will stay the same if your program is single-threaded or uses multiprocessing/asyncio. The changes only affect programs that start threads, in which case you need to take care of synchronization anyway.

Re: Python 3.13.0 Is Released

#96

Post by nyrikki »

CJefferson wrote: post #12

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.

You are complaining about spawn()?

both fork() and spawn() are just wrappers around clone() on most libc types anyway.

spawn() was introduced to POSIX in the last century to address some of the problems with fork() especially related to multi threading, so I an curious how your code is so dependent on UTM, yet multi threading.

Re: Python 3.13.0 Is Released

#97

Post by bunderbunder »

dangom wrote: post #83
bunderbunder wrote: post #47

Earlier quoted context omitted.

But they've worked very hard at shielding most users from that complexity. And the end result - making multithreading a truly viable alternative to multiprocessing for typical use cases - will open up many opportunities for Python users to simplify their software designs. I suppose only time will tell if that effort succeeds. But the intent is promising.

Do you have any references or examples that describe how this simplification would come about? Would love to learn more about it.

See the motivation section of the PEP for a summary with citations for further reading: https://peps.python.org/pep-0703/

Re: Python 3.13.0 Is Released

#98

Post by tightbookkeeper »

kstrauser wrote: post #94
tightbookkeeper wrote: post #88

Earlier quoted context omitted.

You can imagine that situation. But all python code is now impacted to support that case. Having a “python only” ecosystem makes about as much sense as a “bash only” ecosystem. Your tech stack includes much more. > In other worse, I know what I'm doing, I've been doing this since the 90s ditto. So that’s not relevant.

Sounds like a lot of speculation on your end because we don't have lots of evidence about how much this will affect anything , because until just now it's not been possible to get that information. > ditto. So that’s not relevant. Then I'm genuinely surprised you've never once stumbled across one of the many, many use cases where multithreaded CPU-intensive code would be a nice, obvious solution to a problem. You see…

> Sounds like a lot of speculation on your end

This issue is discussed extensively in “the art of Unix programming” if we want to play the authority and experience game.

> multithreaded CPU-intensive code would be a nice, obvious solution to a problem

Processes are well supported in python. But if you’re maxing your CPU core with the right algorithm then python was probably the wrong tool.

> my experience has been that these are very real.

When you’re used to working one way it may seem impossible to frame the problem differently. Just to remind you this is a NEW feature in python. JavaScript, perl, and bash, also do not support multi threading for similar reasons.

One school of design says if you can think of a use case, add that feature. Another tries to maintain invariants of a system.

Re: Python 3.13.0 Is Released

#99

Post by nyrikki »

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.

> posix_spawn() now accepts None for the env argument, which makes the newly spawned process use the current process environment

That is the thing about fork(), spawn(), and even system() being essential wrappers around clone() in glibc and musl.

You can duplicate the behavior of fork() without making the default painful for everyone else.

In musl systems() calls posix_spawn() which calls clone().

All that changes is replacing a legacy call fork() that is nothing more than a legacy convenience alias with real issues and foot guns with multiple threads.

Post reply on HN