Announcement

Collapse
No announcement yet.

Python 3.12 Released With Linux Perf Integration, Performance Improvements

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Weasel
    replied
    Originally posted by schmidtbag View Post
    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).

    Leave a comment:


  • Weasel
    replied
    Originally posted by uid313 View Post
    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.

    Leave a comment:


  • uid313
    replied
    Originally posted by Weasel View Post
    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.

    Originally posted by geearf View Post

    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.

    Originally posted by szymon_g View Post

    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.

    Leave a comment:


  • uid313
    replied
    Originally posted by timofonic View Post

    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.

    Originally posted by partcyborg View Post

    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.

    Originally posted by cl333r View Post

    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.

    Leave a comment:


  • Vorpal
    replied
    Originally posted by timofonic View Post
    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.

    Leave a comment:


  • Vorpal
    replied
    Originally posted by szymon_g View Post

    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.

    Leave a comment:


  • timofonic
    replied
    Originally posted by Vorpal View Post

    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?

    API documentation for the Rust `comptime` crate.

    Leave a comment:


  • guglovich
    replied
    - 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.​

    Leave a comment:


  • cl333r
    replied
    Originally posted by Vorpal View Post

    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.

    Leave a comment:


  • szymon_g
    replied
    Originally posted by uid313 View Post
    [*]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?

    Leave a comment:

Working...
X