281–290 of 302 posts
Earlier quoted context omitted.
It's literally the summary at the top of the article Doesn't anyone click on links anymore?
just trying to compliment the author on a useful blogpost, calm down.
Earlier quoted context omitted.
What do you mean it already runs in threads? It does so if you specify it with run_in_executor [1], or if you run multiple event loops at once, but it doesn't automatically. [1] https://docs.python.org/3/library/asyncio-eventloop.html#asy...
Woops, yeah, you're right. I thought the default executor was a threadpool, my mistake. However, in that case, I assume that the default executor will not change to multithreaded when no-gil comes.
Earlier quoted context omitted.
I think argparse works fine. What worries me is that it's also "soft-deprecated", because devs have said it should get no further development. I hope it stays around, because I use it by default as a no-dependencies solution that I know how it works.
Wait.. source? If argparse isn't getting more development, what's the current alternative?
feature frozen doesn't sound so bad. It just risks sliding into "we don't want to maintain it because it has known problems". (My opinion: Everything well used has known problems, it's ok.)
Earlier quoted context omitted.
Correct, it will help with CPU-limited, embarrassingly parallelizable problems... which are much less common than you think.
Embarrassingly parallelizable problems are extremely common in my life. I end up breaking out of python to use gnu-parallel, which is fine but annoying.
Earlier quoted context omitted.
Pedantic nerd nitpick: it gives you concurrency but not parallelism. (Concurrent threads can be time sliced on one core)
It was clear from the context that he meant concurrently running not concurrently in progress. I wish nerds would give up on this parallelism/concurrency pedantry or at least choose some new nomenclature that didn't conflict so massively with the English meaning of "concurrent". I mean it's not even right. Most parallel/concurrent pedants would consider multithreaded code to be "parallel" even if it is running on a s…
Earlier quoted context omitted.
Pedantic nerd nitpick: it gives you concurrency but not parallelism. (Concurrent threads can be time sliced on one core)
It was clear from the context that he meant concurrently running not concurrently in progress. I wish nerds would give up on this parallelism/concurrency pedantry or at least choose some new nomenclature that didn't conflict so massively with the English meaning of "concurrent". I mean it's not even right. Most parallel/concurrent pedants would consider multithreaded code to be "parallel" even if it is running on a s…
If you're using these as technical terms which have specific technical definitions, then concurrency and parallelism are distinct but related concepts, and parallel computing means executing code simultaneously on separate execution units, not time sliced on a single core. So yes I am actually right about this. Parallel computing is defined this way in CS and it's not a matter of opinion.
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…
Earlier quoted context omitted.
> currently you can't do it at all Is not true. First of all, Python threads are mapped to OS threads. So, you can do "something". Now, in CPython C API there are tools for releasing and acquiring the global lock. They aren't complicated, and I used them in my own extensions. Not sure how popular across other extensions is this practice, but, at least some do use it. Some Python native functions release and acquire t…
> So, you can do "something". You can only do "something" if that doesn't involve interpreting actual Python code. Which is a pretty big deal since we're talking about Python programming.
Python library functions evolved from being simple and somewhat transparent into hugely complicated environments, possibly with their own interpreters that can be programmed by the same programmer who writes the Python program.
While this is an unguided, hugely inefficient ad hoc process, it is this whole mess. Thus, people who write "Python programs" are actually writing programs in Python + a bunch of crappy unter-languages that operate at or even cross different layers of abstraction. And we still call this "mess" a Python program. Eg. Jinja templates or Nuitka decorators or IPython "magic" or Cython etc.
So, in practical terms, there's a lot of what's going on in a Python program, because often a lot and sometimes most of it isn't written in Python proper, Python is just a kind of entry point to that mess, and is used as a label for a thing that nobody cared to give a proper name.
Earlier quoted context omitted.
> your average python dev can just ignore it if they want to. Oh, so naive... All the mutation code in Python which "worked" because Python didn't really have any real concurrency. Add to it -- there's no real plan about what to do with Python concurrency. Removing GIL is only one "half" of the problem, you need to give developers some sort of a framework to use to deal with concurrency. Python's threads are extremel…
> So, all synchronization requires dealing with locks, mutexes, condition variables... As always, by far the best way to interact between threads is to use thread-safe queues (AKA message passing). Luckily, Python has one of those [1]. No complicated synchronisation needed. [1] https://docs.python.org/3/library/queue.html
The reason to want threads is to be able to share memory. That's literally why they were created. If you are sending messages instead of sharing memory, you don't need threads. You need something like Erlang processes.
The problem is that people who wrote Python never had a plan. They sucked and still suck as programmers. So... they knew there are threads. And it was easy to write a bunch of wrappers around pthreads. And that's what they did. And then they realized they don't know how to deal with concurrency, so they found a simple way out -- GIL.
The whole history of Python is the history of choosing the easy but wrong. And it's probably the only consistent thing about the language.