301–310 of 460 posts
There was always a denial of removing the Global Interpreter Lock because it would decrease single threaded Python speed for which most people din’t care. So I remember a guy recently came up with a patch that both removed GIL and also to make it easier for the core team to accept it he added also an equivalent number of optimizations. I hope this release was is not we got the optimizations but ignored the GIL part.…
Earlier quoted context omitted.
Why should major technology projects be "friendly" to random people? I think the word you're looking for is "politics".
Being friendly is inclusive and generally a winning strategy compared to others. The underlying source of the Politics of Python and associated perceptions stems from the core team's culture of not being "friendly".
They have no obligation to go out of their way to cater to yours.
The entitlement of the new generation of open-source contributors to require political correctness or friendliness is so destructive it's ridiculous. I wouldn't want to be involved with any project that prioritizes such zealotry on top of practicality.
One of the biggest features I'm looking forward to is the more specific error messages. I can't tell you how much time I've wasted with cryptic errors that just point to a line that has a list comprehension or similar.
I've been learning Rust recently. There are a number of things about the language that I dislike, but its error messages are an absolute joy. They clearly put an incredible amount of effort into them, and it really shows.
Earlier quoted context omitted.
IMHO majority of Python software doesn't use threads because it is easier to write single threaded code (for many reasons), not because of GIL.
In Golang you can spawn a green thread on any function call with a single keyword: `go'. The ergonomics are such that it's not difficult to use. Why can't or shouldn't we have a mechanism comparably fantastic and easy to use in Python?
These speedups are awesome, but of course one wonders why they haven't been a low-hanging fruit over the past 25 years. Having read about some of the changes [1], it seems like the python core committers preferred clean over fast implementations and have deviated from this mantra with 3.11. Now let's get a sane concurrency story (no multiprocessing / queue / pickle hacks) and suddenly it's a completely different lang…
Because Guido van Rossum just isn't very good with performance, and when others tried to contribute improvements, he started heckling their talk because he thought they were “condescending”: https://lwn.net/Articles/754163/ And by this time, we've come to the point where the Python extension API is as good as set in stone. Note that all of the given benchmarks are microbenchmarks; the gains in 3.11 are _much_ less pr…
Earlier quoted context omitted.
> the vast majority of Python software is written as single-threaded. This is a self-fulfilling prophecy, as the GIL makes Python's (and Ruby's) concurrency story pretty rough compared to nearly all other widely used languages: C, C++, Java, Go, Rust, and even Javascript (as of late).
Getting rid of the GIL will also immediately expose all the not-thread-safe stuff that currently exists, so there's a couple of waves you would need before it would be broadly usable.
As a python dev, pythons multiprocess/multithreading story is one the largest pain points in the language.
Single threaded performance is not that useful while processors have been growing sideways for 10 years.
I often look at elixir with jealousy.
Earlier quoted context omitted.
Indeed, and that's why I love it. When I need extra performance, which is very rarely, I don't mind spending extra effort outsourcing it to a binary module. More often, the problem is an inefficient algorithm or data arrangement. I took a graduate level data structures class and the professor used Python among other things "because it's about 80 times slower than C, so you have to think hard about your algorithms". A…
Global Interpreter Lock (GIL) is also an issue affecting Python execution speed: https://en.wikipedia.org/wiki/Global_interpreter_lock
It prevents you from taking advantage of multiple cores. Doesn't really impact straight-line execution speed.
A data structures course is primarily not going to be concerned with multithreading.
Earlier quoted context omitted.
This is the first time I ever heard someone complain about Python's error messages in the 10+ years I've been using it. Even people who just learned it, pick up reading tracebacks after about a day of practice. The only problem I ever see is if a library swallows too much, and gives a generic error, but that's not something the language can fix. I really hope they don't change things too much.
The new error messages are much better. Take a look at this example: Traceback (most recent call last): File "calculation.py", line 54, in result = (x / y / z) * (a / b / c) ~~~~~~^~~ ZeroDivisionError: division by zero In this new version it's now obvious which variable is causing the 'division by zero' error. https://docs.python.org/3.11/whatsnew/3.11.html#enhanced-err...
Stack trace is useful, especially in understanding how the code is working in the system.
But if the goal is solve the problem with the code you've been working on, existing traces are way too verbose and if anything add noise or distract from getting to productive again.
I could see tracebacks get swifty terminal UI that shows only the pinpointed error point that can be accordion'd out to show the rest.
Earlier quoted context omitted.
Yours is nice and readable. Parents' one is not, but it feels like the indentation is deliberately confusing. I'd lay it out like so: tags = list(set([ nel for subli in [ mel for subl in [ [[jel.split('/')[2:] for jel in el] for el in classified ] for mel in subl ] for nel in subli if nel ])) Still not very readable, tho. But that's largely due to Python's outputs-first sequence comprehension syntax being a mess that…
Does the new walrus := in python solve your problem?