Python 3.13 Sees Last Minute Delay Due To Performance Regression

[phoronix]

Phoronix: Python 3.13 Sees Last Minute Delay Due To Performance Regression

Python 3.13 had been scheduled for release today with a new interactive interpreter, experimental free-threaded build mode to disable the Global Interpreter Lock (GIL), an experimental JIT, and other shiny new features. But a performance regression has delayed the Python 3.13 release to next week and in turn an unexpected Python 3.13-rc3 final test release...

https://www.phoronix.com/news/Python-3.13-rc3-Released

[uid313]

Is the new interactive interpreter good enough to replace IPython?

Python is not so good because you cannot do top-level await, you must specify a async executor. You cannot serialize JSON to a class (yeah, there are some dirty tricks to get around it, and some third-party libraries that will do it for you. It is tricky to work with HTTP because urllib is not friendly, so you need a third-party library like requests, httpx, etc.

I think Python should have better out-of-the-box support for HTTP and JSON.

[kieffer]

3.13 marks the beginning of the migration to Python4 ... I have the feeling many trouble is ahead for normal Python developers like me.

[blackshard]

Is the new interactive interpreter good enough to replace IPython?

Python is not so good because you cannot do top-level await, you must specify a async executor. You cannot serialize JSON to a class (yeah, there are some dirty tricks to get around it, and some third-party libraries that will do it for you. It is tricky to work with HTTP because urllib is not friendly, so you need a third-party library like requests, httpx, etc.

I think Python should have better out-of-the-box support for HTTP and JSON.

You have been already answered to the very same question in previous threads, there is no need to repeat everytime these very same non-issues about python.

[fitzie]

3.13 marks the beginning of the migration to Python4 ... I have the feeling many trouble is ahead for normal Python developers like me.

no-GIL has you scared? i do think we're a fair ways off from python4, and if and when it will happen I will be much more nuanced than 2to3 was. I think it's much more likely for something like mojo to be python4, which just coexists with cpython 3.x in perpetuity

[fitzie]

this is pretty embarassing that a major python ecosystem software like sphinx wasn't in the faster python benchmark suite (it was sphinx testing the rc that caused the new GC to be reverted). python should reach out to all their top software to get beta/rc builds into their respective CIs. As it stands now, the rule of thumb you should always stay one release behind with python. I'm looking forward to moving my code to 3.12 once 3.13 is out. It would be nice if the rule of thumb were wait until 3.x.2 before moving to the latest version, which would be a massive step forward. Although the python we have today is so much better than the pre 3.5 days and the ecosystem has been really good moving forward. many popular libraries don't even support before 3.7, which is a really good thing.

[npwx]

Looking at type syntax:

StartT = TypeVar("StartT", default=int)
StopT = TypeVar("StopT", default=StartT)
StepT = TypeVar("StepT", default=int | None)

class slice(Generic[StartT, StopT, StepT]): ...

reveal_type(slice) # type is type[slice[StartT = int, StopT = StartT, StepT = int | None]]
reveal_type(slice()) # type is slice[int, int, int | None]
reveal_type(slice[str]()) # type is slice[str, str, int | None]
reveal_type(slice[str, bool, timedelta]()) # type is slice[str, bool, timedelta]

T2 = TypeVar("T2", default=DefaultStrT)

class Foo(Generic[DefaultStrT, T2]):
def __init__(self, a: DefaultStrT, b: T2) -> None: ...

reveal_type(Foo(1, "")) # type is Foo[int, str]
Foo[int](1, "") # Invalid: Foo[int, str] cannot be assigned to self: Foo[int, int] in Foo.__init__
Foo[int]("", 1) # Invalid: Foo[str, int] cannot be assigned to self: Foo[int, int] in Foo.__init__

Is this still considered "Pythonic"? To me, that's a completely unreadable mess.

[jacob]

Is the new interactive interpreter good enough to replace IPython?

Python is not so good because you cannot do top-level await, you must specify a async executor. You cannot serialize JSON to a class (yeah, there are some dirty tricks to get around it, and some third-party libraries that will do it for you. It is tricky to work with HTTP because urllib is not friendly, so you need a third-party library like requests, httpx, etc.

I think Python should have better out-of-the-box support for HTTP and JSON.

I think not allowing to serialize/deserialize JSON to/from a class is a feature, not a bug. The lack of top level await is a nuisance for thr user but there are good reasons for it. Python is not really meant to be a batteries included language, that's JavaScript and it's unbeatable at that. Python takes a different approach and it has been extremely successful at what it is as well.

[caligula]

Wow these changes almost transform python into a real programming language. PHP already improved its status some time ago. Python is still one of the joke languages for children.

[mulenmar]

While I would say Python is the language to make your prototypes in near the speed of thought, before taking the polished algorithms to something native and better at well-handled threading, I would not go so far as to declare it a toy. Real work is done in and with it, and Arch's package manager is written in Python iirc.

Programs like Calibre becoming utterly unresponsive whenever a plugin like FanFicFare is working (before it starts the download proper) may give that impression of toy-status, though, I won't disagree there, but that codebase was itself a mess last I checked.