[Python-ideas] Python 3000 TIOBE -3%

Yuval Greenfield ubershmekel at gmail.com
Fri Feb 10 11:52:09 CET 2012

> Also, AFAIK Ruby has a GIL much like Python. I think it's time to start a
> PR offensive explaining why these are not the problem the trolls make them
> out to be, and how you simply have to use different patterns for scaling in
> some languages than in others.

GIL + Threads = Fibers

CPython doesn't have threads but it calls its fibers "threads" which causes
confusion and disappointment. The underlying implementation is not
important eg when you implement a "lock" using "events" does the lock
become an event? No. This is a PR disaster.

100% agree we need a PR offensive but first we need a strategy. Erlang
champions the actor/message paradigm so they dodge the threading bullet
completely. What's the python championed parallelism paradigm? It should be
on the front page of python.org and in the first paragraph of wikipedia on

One of the Lua authors said this about threads:
> (I can't remember the quote so I will paraphrase)
> "How can you program in a language where 'a = a + 1' is not deterministic?"
> Indeed.

Anyone who cares enough about performance doesn't mind that 'a = a + 1' is
only as deterministic as you design it to be with or without locks.
Multiprocessing has this same problem btw.

What Python needs are better libraries for concurrent programming based on
> processes and coroutines.

The killer feature for threads (vs multiprocessing) is access to shared
state with nearly zero overhead.

And note that a single-threaded event-driven process can serve 100,000 open
> sockets -- while no JVM can create 100,000 threads.

Graphics engines, simulations, games, etc don't want 100,000 threads, they
just want true threads as many as there are CPU's.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20120210/3981ce01/attachment.html>

More information about the Python-ideas mailing list