Python 3.12 Released With Linux Perf Integration, Performance Improvements

[Weasel]

Python... the source of much hair pulling

The worst in this aspect. Nothing comes close with its dependency hell and versions.

[schmidtbag]

The worst in this aspect. Nothing comes close with its dependency hell and versions.

I've had more of such issues with PHP. I haven't had them with Python - either stick with your distro's repo or use pip. Of course, maybe with Windows it's a bit harder.

[zexelon]

Gotta say, having done a ton of work in PHP, a small amount in C++, Python is vastly superior. Tried out Perl a very long time ago and could not stomach it. Python is easy to make maintainable code in. Sure its performance can suck for certain very performance sensitive applications... but most of those are cases handled by external libraries written in much higher performance task specific languages.

[Vorpal]

What's your opinion about Zig (the programming language)? I just found out about it.

I haven't looked at it in detail. It has some neat ideas (such as comptime) but it doesn't guarantee memory safety like Rust does. I'm struggling to see the niche it is trying to fill. I'm probably not going to learn it myself, as I don't see why I would choose it over any language that I already know.

If it had arrived contemporary with C or even C++, then it would been a different situation. But now it seems marginally better but without the huge ecosystem of libraries that established languages have. And I would choose rust over it every time basically these days. Memory safety and the borrow checker saves soo much time debugging.

[geearf]

Gotta say, having done a ton of work in PHP, a small amount in C++, Python is vastly superior. Tried out Perl a very long time ago and could not stomach it. Python is easy to make maintainable code in. Sure its performance can suck for certain very performance sensitive applications... but most of those are cases handled by external libraries written in much higher performance task specific languages.

I too have always enjoyed writing stuff in python (well apart from working around the GIL, and what I thought was a very ugly async syntax, but I think that may have been fixed since), but is this still true today vs Go and alike? These languages too are pretty simple but they are quite faster.

[zexelon]

I too have always enjoyed writing stuff in python (well apart from working around the GIL, and what I thought was a very ugly async syntax, but I think that may have been fixed since), but is this still true today vs Go and alike? These languages too are pretty simple but they are quite faster.

I have not tried Go to date. For what I do there are not a lot of languages supported. Python turned out to be a bit of a unicorn at the intersection of a number of fields. I have looked at Go code and it "looks" interesting but some of its design choices did not make sense to me. That is not a judgment on the language, more so on my lack of time to invest in understanding the design paradigms.

The GIL is an interesting issue with Python for sure. There are a number of strategies that are well supported for getting around it. I think its one of those early design decisions that was done for expediency early on. It made sense and was not a bad choice... it just became a HUGE headache when things scaled beyond the designers original vision... its always fun as a software dev when the users push the limits of what you designed for...

[kpedersen]

Python got plenty of other problems though.

The only one that makes it a true dealbreaker for me is that Python's current garbage collector doesn't handle circular references so common architectures involving hierarchy and parent / child references (think XML DOM / JSON nodes) will leak memory.

Frustratingly so few Python developers know what weakref is that leaks are rampant in Python / PIP libraries.

Same issue with Perl / Scalar::Util::weaken to be fair.

So if I am going to be handling this manually, I might as well just go the full way and use C++ along with i.e std::shared_ptr<T> and std::weak_ptr<T> counterpart for those software designs.

[szymon_g]

[*]It sucks for embedding into other software because there is no way to limit what it can do. Any script will have full access to anything and everything.

out of curiosity, as a non-developer- how is that solved in other interpreted languages?

[cl333r]

I haven't looked at it in detail. It has some neat ideas (such as comptime) but it doesn't guarantee memory safety like Rust does. I'm struggling to see the niche it is trying to fill. I'm probably not going to learn it myself, as I don't see why I would choose it over any language that I already know.

If it had arrived contemporary with C or even C++, then it would been a different situation. But now it seems marginally better but without the huge ecosystem of libraries that established languages have. And I would choose rust over it every time basically these days. Memory safety and the borrow checker saves soo much time debugging.

Yeah, any established lang has a huge advantage over Zig simply because of the ecosystem, libs, etc.
And yeah there can be many dealbreakers like if mem safety is important enough.
But it's definitely much better than C and even tries to implement/emulate OO stuff, imho people should teach Zig instead of C in schools.

I don't like the name and that to print out smth is way too verbose, perhaps even more verbose than in Java (System.out.println).
Random thoughts.

[guglovich]

- The flexibility of f-string parsing (formatted literals prefixed with 'f') has been improved, removing many restrictions. For example, inside f-lines, you can now specify any Python-valid expression, including multi-line expressions, comments, backslashes, and escape sequences for Unicode. In addition, it is now allowed to reuse the same quotes in the inner string as in the framing of the f-string (i.e. double quotes can now be reused inside without switching to single quotes). Error messages for f-string errors have been made more informative, now indicating the exact place in the string that caused the error.

- Support for isolated subinterpreters and separate global interpreter locks (GIL, Global Interpreter Lock) for different interpreters within a process (CPython allows multiple interpreters to run in the same process). In its current form, the feature is only available through the C-API for now (Python API support will appear in the next major branch).

- The buffer protocol feature has been added to Python code. Classes that provide the "__buffer__()" method can now be used as types that work directly with binary data in memory.

- Offered a sys.monitoring module for debugging and profiling that allows you to monitor CPython events such as calls, returns from functions, execution of arbitrary lines of code, exceptions, and transitions with minimal overhead.

- The interpreter includes support for the Linux perf kernel subsystem, which allows you to define Python function names when profiling with the perf utility (previously, only C function names were defined in traces).

- The informative nature of error messages has been improved and the range of exceptions that offer recommendations on how to fix typos has been expanded. For example, now recommendations on importing forgotten modules of the standard library are displayed, hints on adding the prefix "self." in methods are shown, the spelling "import x from y" instead of "from y import x" is defined etc.

- A new more compact type annotation syntax for generalized classes and functions is proposed.

- A new way of defining type aliases using the "type" expression is provided

- Added a new @override decorator to the typing module to inform type checking systems that a method in a subclass is intended to override a method or attribute in a superclass. The decorator can be used to detect errors related to the fact that a method intended for override does not perform the given action.

- In order to enhance security, the built-in implementations of SHA1, SHA3, SHA2-384, SHA2-512 and MD5 algorithms in hashlib have been replaced by formally verified variants from the HACL* project (built-in implementations are used only if OpenSSL is not available).

- Stack overflow protection is implemented in СPuthon.

- Support for subclasses is implemented in pathlib.Path class.

- In the os module, support for the Windows platform has been extended. For example, when working in Windows, support for os.listdrives(), os.listvolumes() and os.listmounts() methods has been added, and the accuracy of os.stat() and os.lstat() has been improved.

- Command line interfaces ("python -m sqlite3" and "python -m uuid") have been added to the sqlite3 and uuid modules.

- Added support for "immortal" objects for which reference counting is not applied to C-API.

- Implemented the concept of an unstable level C API for use in debuggers, JIT compilers, and other low-level tools.

- Cleanup of deprecated features has been performed.