Matteo Cafasso added the comment:
On 09/10/13 22:59, Richard Oudkerk wrote:
Yes. But my point was that somebody might have used such a function as the
initializer argument. The proposed change would break a program which does
with Pool(initializer=os.nice, initargs=(incr,)) as p:
Matteo Cafasso added the comment:
On 07/10/13 13:32, Richard Oudkerk wrote:
Richard Oudkerk added the comment:
I think misuse is an exageration. Various functions change some state and
return a value that is usually ignored, e.g. os.umask(), signal.signal().
These functions are compliant
Richard Oudkerk added the comment:
These functions are compliant with POSIX standards and the return values
are actually useful, they return the previously set masks and handlers,
often are ignored but in complex cases it's good to know their previous
state.
Yes. But my point was that
Matteo Cafasso added the comment:
I agree with your point, I've probably made my considerations too quickly.
The consideration was based on the fact that returning any value previously was
a misuse (without consequences) of the initializer itself.
Now the misuse would be exposed by the new
Richard Oudkerk added the comment:
I think misuse is an exageration. Various functions change some state and
return a value that is usually ignored, e.g. os.umask(), signal.signal().
Global variables usage is a pattern which might lead to code errors and many
developers discourage from
New submission from Matteo Cafasso:
This patch allows the pool initializer function to return the initialized
values. The returned values will be passed to the called function as first
positional argument.
Previously the common pattern was to store the initialized objects into global
Richard Oudkerk added the comment:
the previous initializers were not supposed to return any value
Previously, any returned value would have been ignored. But the documentation
does not say that the function has to return None. So I don't think we can
assume there is no compatibility