Future of Pypy?

[Paul Rubin]

Ryan Stuart <ryan.stuart.85 at gmail.com> writes:
> Many people have written at length about why it's bad. The most recent
> example I have come across is here ->
> https://glyph.twistedmatrix.com/2014/02/unyielding.html

That article is about the hazards of mutable state shared between
threads.  The key to using threads safely is to not do that.  So the
"transfer" example in the article would instead be a message handler in
the thread holding the account data, and it would do the transfer in the
usual sequential way.  You'd start a transfer by sending a message
through a Queue, and get back a reply through another queue.

In Erlang that style is enforced: it has basically no such thing as data
mutation or sharing.  In Python it's straightforward to write in that
style; it's just that the language doesn't stop you from departing from
it, sort of like a language with weak type-checking.  You can survive it
if the code complexity isn't too bad.  In most programs I've dealt with,
the number of distinct handlers is not all that large (there might be
1000 threads in a high-concurrency network server, but they're all doing
about the same thing).  So it hasn't been that hard to "color inside the
lines" with a bit of thoughtfulness and code inspection.

You might like this:

http://jlouisramblings.blogspot.com/2012/08/getting-25-megalines-of-code-to-behave.html