Python 3.12 Released With Linux Perf Integration, Performance Improvements

[timofonic]

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.

What about this?

https://docs.rs/comptime/latest/comptime/

https://docs.rs/constime/latest/constime/

[Vorpal]

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

A few different ways, all generally fall under the label of sandboxing. Generally you limit what the program can access by forbidding everything except a small list of allowed things.

Python really isn't built with this in mind, there are too many holes to plug. While something like wasm on the other end of the spectrum can't do anything outside it's own memory and code by default, everything else has to be explicitly exposed to it by the host program.

[Vorpal]

What about this?

https://docs.rs/comptime/latest/comptime/

https://docs.rs/constime/latest/constime/

Interesting. It does come with caveats listed in the docs, and I suspect it will be kind of janky. Probably slow as well. But nice proof of concept.

[uid313]

What would you suggest? Perl? Haskell? Lua?

Suggest for what?

As a language to embed for scripting within another application?
Well, Perl is shittier in every way.
Haskell is known by too few, mostly in academia, it is not mainstream and for scripting you would want something with broad appeal that is commonly known, so that would be Python.
Lua offers better performance than Python so if that is important, then Lua is a good choice, but Python is known by more people.

If you didn't ask for a suggestion for a language to embed, then for system-level programming I would suggest Rust or Zig. For application and business applications I would suggest C# on the .NET platform.

Don't get me wrong though, I am not saying that you shouldn't use Python or that Python is horrible and that it sucks. I find myself coding in Python too, and there are things to like about it too, I am just saying that Python has a couple of weak points, and things that I wish were better. Other languages got drawbacks and warts too.

Just a couple of days ago, I started writing a new Python script.

I agree this sucks, but given that classes aren't strongly typed in python I don't think it would be possible to write a generic deserializer.

I heard there is a third-party Python package that can do deserialize JSON into classes, so I think it is just the standard library that is shitty. It doesn't sound like a hard problem to solve. I could probably write it myself using the hasattr and setattr functions.

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

I have only used it a little bit, but I liked it.
Now you cant compare it to Python because Python is a high-level interpreted language while Zig is a low-level, compiled system language so you would have to compare Zig with C, C++, D and Rust.
Zig is way nicer than C.

If you have coded in C then you should defeinitly check out Zig, it is great!
If you're into low level programming and systems programming then you should definitely check out Zig, it is great!
If you're into high level languages like Python or JavaScript then while Zig is good, it might not be something you would appreciate because it is not as easy.

But if you like Python then do Python. I've criticized Python some, but I am not saying it is an all bad language or that other languages are better. Other languages got their warts too.

[uid313]

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

I haven't used Ruby much, but we had to use it briefly at work and we experienced dependency problems with RubyGems, so we moved away Middleman written in Ruby to Hugo written in Go.

I haven't used Perl much recently either, but I think it is pretty bad too. They got like CPAN, something very old.

Then there is JavaScript where you use Node.js and if you want to fetch one little dependency you'll end up with 100k files in your node_modules directory.

Then you have .NET Framework where in larger solutions with many project references you could end up with dependencies that had incompatible version requirements so would end up with runtime crashes that you had to track down and attempt to solve with BindingRedirects, it was hell. Modern .NET (since .NET Core, not .NET Framework) is great though.

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.

Go is much faster than Python.
Personally, I don't like Go though, mostly because of minor things though that has to do with syntax though, such as you have to put functions that belong to a struct outside of the struct instead of within the struct. Oh, and how the code formatter doesn't want you to have any space between braces or brackets.

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

I don't know.
I haven't worked much with embedding scripts in other applications so I don't know much about it.
I have limited experience only with having my Python application running Python scripts and it is not secure, those scripts can do anything on the system and modify and do anything within the application it runs.

[Weasel]

I haven't used Ruby much, but we had to use it briefly at work and we experienced dependency problems with RubyGems, so we moved away Middleman written in Ruby to Hugo written in Go.

I haven't used Perl much recently either, but I think it is pretty bad too. They got like CPAN, something very old.

Then there is JavaScript where you use Node.js and if you want to fetch one little dependency you'll end up with 100k files in your node_modules directory.

Then you have .NET Framework where in larger solutions with many project references you could end up with dependencies that had incompatible version requirements so would end up with runtime crashes that you had to track down and attempt to solve with BindingRedirects, it was hell. Modern .NET (since .NET Core, not .NET Framework) is great though.

You're not wrong, those are full of dependency hell as well, especially node.js. But python is worse from my experience (.NET, though, is the most bloated, by far).

The problem with Python is so big it even created "virtual environments" to solve this problem, somewhat. Problems that stem not just from libraries that have conflicting versions (e.g. X works with Y version 5, but not 5.5, while another one needs Y 5.5), but also python itself (e.g. 3.11 vs 3.12 may be totally incompatible with some dependencies and packages), venv store even the python executables. It's disgusting (and I know first hand from trying to setup various AI workloads, which for some reason they all use python, and it's the worst nightmare I ever had with anything so far in my life).

.NET is bad, mostly because it supplies each independent minor version of libraries/deps, but at least you can mix and match them, unlike in Python. It's more bloated though (as in disk space), which is also disgusting.

[Weasel]

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.

See my post above to uid313. Python by itself is easy to compile actually, that's not the problem lol. It's the projects that use it (new python versions can break old scripts/code), and the insane dependency hell of python packages (that require specific versions or whatever, there's just so many combinations and stuff breaking over time).