[Python-ideas] fork

Sven R. Kunze srkunze at mail.de
Tue Aug 11 16:33:04 CEST 2015


Am 05-Aug-2015 16:30:27 +0200 schrieb abarnert at yahoo.com:

> What does that even mean? How would you not allow races? If you let people throw arbitrary tasks at a thread pool, with no restriction on mutable shared state, you've allowed races.

Let me answer this in a more implicit way.

Why do we need to mark global variables as such?
I think the answer is clear: to mark side-effects (quoting the docs).

Why are all variables thread-shared by default?
I don't know, maybe efficiency reasons but that hardly apply to Python in the first place.

> And how do you propose "not having them"?

What would happen if all shared variables were thread-local by default and need to marked as shared if desired?
I think the answer would also be very clear: to mark side-effects and to have people think about it explicitly.

> And that's exactly the problem. What makes concurrent code with shared state hard, more than anything else, is people who don't realize what's hard about it and write code that seems to work but doesn't.

Precisely because 'shared state' is hard, why is it the default?

> Making it easier for such people to write broken code without even realizing they're doing so is not a good thing.

That argument only applies when the broken code (using shared states) is the default.

As you can see, this thought experiment assumes that there could be another way to approach that situation. How and when this can be done and if at all is a completely different matter. As usual, I leave that to the experts like you to figure out.

Best,
Sven

-------------------------------------------------------------------------------------------------
FreeMail powered by mail.de - MEHR SICHERHEIT, SERIOSITÄT UND KOMFORT
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150811/387917c0/attachment-0001.html>


More information about the Python-ideas mailing list