[flagged]
If you're making claims about defamation and libel, at least be specific.
Discussion of one of the victims of the Steering Council:
Python 3.13.0 Is Released
81–90 of 135 posts
Re: Python 3.13.0 Is Released
#82Earlier quoted context omitted.
> I really like using Python, but I can’t keep using it when they just keep breaking things like this. So much perl clutching. Just curious, since I guess you've made up your mind, what's your plan to migrate away? Or are you hoping maintainers see your comment and reconsider the road-map?
Not the person you are responding to, but my Python 3 migration plan was to move to Go for all new projects.
I'm sure your departure from the community will be the tectonic shift that'll finally get the PSF to change their course.
Re: Python 3.13.0 Is Released
#83Earlier quoted context omitted.
Removing GIL only increases complexity.
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.
Re: Python 3.13.0 Is Released
#84Earlier quoted context omitted.
> No. Python is orders of magnitude slower than even C# or Java. That sounds like a fantastic reason to make it run faster on the multi-core CPUs we're commonly running it on today.
The cost to write and debug multithreaded code is high and not limited to the area you use it. And for all that you get a 2-8x speed up. So if you care about performance why are you writing that part in python? > multi-core CPUs we're commonly running it on today. If you spawn processes to do work you get multi core for free. Think of the whole system, not just your program.
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 since the 90s, and I can imagine this improvement unlocking a whole lot of use cases that've been previously unviable.
Re: Python 3.13.0 Is Released
#85I has officially been released: https://blog.python.org/2024/10/python-3130-final-released.h...
Re: Python 3.13.0 Is Released
#86Python 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.
For those interested in the REPL improvements: " Python now uses a new interactive shell by default, based on code from the PyPy project. When the user starts the REPL from an interactive terminal, the following new features are now supported: Multiline editing with history preservation. Direct support for REPL-specific commands like help, exit, and quit, without the need to call them as functions. Prompts and traceb…
No vi editing mode :-(
> The new REPL will not be implementing inputrc support, and consequently there won't be a vi editing mode.
https://github.com/python/cpython/issues/118840#issuecomment...
Re: Python 3.13.0 Is Released
#87Earlier quoted context omitted.
For those interested in the REPL improvements: " Python now uses a new interactive shell by default, based on code from the PyPy project. When the user starts the REPL from an interactive terminal, the following new features are now supported: Multiline editing with history preservation. Direct support for REPL-specific commands like help, exit, and quit, without the need to call them as functions. Prompts and traceb…
Presumably this also means readline (GPL) is no longer required to have any line editing beyond what a canonical-mode terminal does by itself. It seems like there is code to support libedit (BSD), but I've never managed to make Python's build system detect it.
I have managed to build Python with libedit instead of readline, but it was a custom build.
If your assumption is correct, then I'm anxiously waiting for having the default Python executable in Ubuntu, for example, being licensed under a non-copyleft license. Then one would be able to build proprietary-licensed executables via PyInstaller much more easily.
Re: Python 3.13.0 Is Released
#88Earlier quoted context omitted.
The cost to write and debug multithreaded code is high and not limited to the area you use it. And for all that you get a 2-8x speed up. So if you care about performance why are you writing that part in python? > multi-core CPUs we're commonly running it on today. If you spawn processes to do work you get multi core for free. Think of the whole system, not just your program.
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.
Re: Python 3.13.0 Is Released
#89And Azure Functions still doesn't support Python 3.12, released more than a year 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.
Re: Python 3.13.0 Is Released
#90What 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.
Also, Py2 ended approaching Euler’s number, 2.7.18.