[Python-ideas] fork

[Sven R. Kunze]

On 04.08.2015 21:38, Andrew Barnert wrote:
> I think anyone who finds the complexity of concurrent.futures too 
> daunting to even attempt to learn it should not be working on any code 
> that uses less explicit concurrency.

I am sorry because I disagree here with you.

> I have taught concurrent.futures to rank novices in a brief personal 
> session or a single StackOverflow answer and they responded, "Wow, I 
> didn't realize it could be this simple".

Nobody says that concurrent.futures is not an vast improvement over 
previous approaches. But it is still not the end of the line of 
simplifications.

> Someone who can't grasp it is almost certain to be someone who 
> introduces races all over your code and can't even understand the 
> problem, much less debug it.

Nobody wants races, yet everybody still talks about them. Don't allow 
races in the first place and be done with it.

> Not true. The language clearly defines when each step happens. The 
> a.__add__ method is called, then the result is assigned to a, then the 
> statement finishes. (Then, in the next statement, nothing 
> happens--except, because this is happening in the interactive 
> interpreter, and it's an expression statement, after the statement 
> finishes doing nothing, the value of the expression is assigned to _ 
> and its repr is printed out.)

Where can find this definition in the docs?

To me, we are talking about class customization as described on 
reference/datamodel.html. Seems like an implementation detail, not a 
language detail.

I am not saying, CPython doesn't do it like that, but I saying the 
Python language could support lazy evaluation and not disagreeing with 
the docs.

> This ordering relationship may be very important if the variable a is 
> shared by multiple threads, especially if more than one thread may 
> modify it, especially if you're using non-atomic operations like += 
> (where another thread can read, use, and assign the variable between 
> the __add__ call and the assignment). If a references a mutable object 
> with an __iadd__ method, the variable doesn't even need to be shared, 
> only the value, for this to matter. The only way to safely ignore 
> these problems is to never share any variables or any mutable values 
> between threads.

Mutual variables are global variables. And these have gone out of style 
quite some time ago.

Btw. this is races again and I thought we agreed on not having them 
because nobody really can/wants to debug them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150804/b33fda28/attachment.html>