What's up, Python? The GIL removed, a new compiler, optparse deprecated

Post by empthought » Mon, Jul 31, 2023, 2:19 AM UTC

antod wrote: post #46

brightball wrote: post #36

Earlier quoted context omitted.

This is actually one of the reasons I was drawn to Ruby over Python. Ruby also has the GIL but jRuby is an excellent option when needed.

I wonder what lead to JRuby attracting support while Jython not? I know the Jython creator went on to other things (was it eg IronPython for dotnet?). I suppose it was the inverse with dotnet - eg IronPython surviving while IronRuby seems dead. Is it just down to corporate sponsorship?

Post by TillE » Mon, Jul 31, 2023, 2:23 AM UTC

oivey wrote: post #118

geysersam wrote: post #103

Earlier quoted context omitted.

How do you mean? 3.11 is something like 10-20% faster than earlier Python releases. Why should that make it comparable to Java? Typically Java is still several times faster than Python, and this is totally natural since Java performance benefits from static type declarations and the language is generally less dynamic than Python. That said I still use Python for CPU intensive tasks since in my experience Numpy/Scipy/…

Static type declarations don't make Java fast. The compiler does. Dynamically typed languages with no type declarations can be very fast if the compiler can infer the types. That's not to say that Python will ever get there. My understanding is that the design of the language and leaky implementation details make generally compiling Python to fast machine code nearly impossible.

Post by thrashh » Mon, Jul 31, 2023, 2:27 AM UTC

chlorion wrote: post #119

alfalfasprout wrote: post #93

Earlier quoted context omitted.

Nowadays multiprocessing is rarely the answer. Between all the gotchas (memory usage can be horrific, have to be careful what you modify, etc.) it's almost never the right answer. Nowadays numba is usually a better solution for when you want to run some computationally expensive python code that itself calls numpy, etc. For the parent commenter's use case though that wouldn't be a great solution either. In general, P…

You have to be much more careful about what you modify when using multithreading, so I'm not sure what you mean by that. A lot of people here mention that sharing data is much easier with multithreading, but doing this without races is not easy. You can't just use the values from difference threads like you would in normal code, you need to synchronize access with locks, which can be difficult to do correctly and can…

Post by swyx » Mon, Jul 31, 2023, 2:45 AM UTC

BiteCode_dev wrote: post #2

Summary: - Python without the GIL, for good - LPython: a new Python Compiler - Pydantic 2 is getting usable - PEP 387 defines "Soft Deprecation", getopt and optparse soft deprecated - Cython 3.0 released with better pure Python support - PEP 722 – Dependency specification for single-file scripts - Python VSCode support gets faster - Paint in the terminal

Post by bmitc » Mon, Jul 31, 2023, 2:51 AM UTC

nwallin wrote: post #53

wmwmwm wrote: post #14

Historically I’ve written several services that load up some big datastructure (10s or 100s of GB), then expose an HTTP API on top of it. Every time I’ve done a quick implementation in Python of a service that then became popular (within a firm, so 100s or 1000s of clients) I’ve often ended up having to rewrite in Java so I can throw more threads at servicing the requests (often CPU heavy). I may have missed somethin…

> I may have missed something but I couldn’t figure out how to get the multi-threaded performance out of Python Multiprocessing. The answer is to use the python multiprocessing module, or to spin up multiple processes behind wsgi or whatever. > Historically I’ve written several services that load up some big datastructure (10s or 100s of GB), then expose an HTTP API on top of it. Use the python multiprocessing module…