[issue26374] concurrent_futures Executor.map semantics better specified in docs

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

I would propose closing since the original doc issue regarding order and map in 
Python 3 is resolved. Just to add there is a PR to make map less eager : 
https://github.com/python/cpython/pull/707/

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26374] concurrent_futures Executor.map semantics better specified in docs

[Brian Quinlan]

Change by Brian Quinlan :


--
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26374] concurrent_futures Executor.map semantics better specified in docs

[Brian Quinlan]

Brian Quinlan  added the comment:

Can we close this bug then?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26374] concurrent_futures Executor.map semantics better specified in docs

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

There were some improvements made that clarify differences between builtin map 
with https://bugs.python.org/issue32306 and 
https://github.com/python/cpython/commit/a7a751dd7b08a5bb6cb399c1b2a6ca7b24aba51d

Thanks

--
nosy: +xtreak

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26374] concurrent_futures Executor.map semantics better specified in docs

[Mark Dickinson]

Mark Dickinson added the comment:

I just noticed this point, which may be confusing things:

> Rebut: order is undefined, concurrent_futures specifies map() returns an 
> iterator, where builtin map returns a list.

In Python 3, the built-in map function returns an iterator, not a list.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26374] concurrent_futures Executor.map semantics better specified in docs

[Mark Dickinson]

Changes by Mark Dickinson :


--
assignee:  -> docs@python
components: +Documentation -Library (Lib)
nosy: +docs@python

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26374] concurrent_futures Executor.map semantics better specified in docs

[Mark Dickinson]

Mark Dickinson added the comment:

Note also this code snippet from PEP 3148:

for number, prime in zip(PRIMES, executor.map(is_prime,
  PRIMES)):

The use of zip here suggests strongly that the intention is that the order of 
the `map` result is well-defined.

It's possible that the docs should be updated to make the ordering requirement 
clearer.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26374] concurrent_futures Executor.map semantics better specified in docs

[Mark Dickinson]

Mark Dickinson added the comment:

The documentation says: "Equivalent to map(func, *iterables)". I believe that 
that equivalency implies that the ordering *is* defined, so it would be 
incorrect to add "order of results is undefined" to the documentation.

--
nosy: +mark.dickinson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26374] concurrent_futures Executor.map semantics better specified in docs

[SilentGhost]

Changes by SilentGhost :


--
components: +Library (Lib)
nosy: +bquinlan

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26374] concurrent_futures Executor.map semantics better specified in docs

[F.D. Sacerdoti]

New submission from F.D. Sacerdoti:

Hello,

My colleague and I have both written parallel executors for the 
concurrent_futures module, and are having an argument, as described in the 
dialog below. To resolve, I would like to add "order of results is undefined" 
to disambiguate the docs for "map(func, *iterables, timeout=None)".

DISCUSSION

Q: Correct Semantics to return results out of order?
JH: No, breaks API as stated
Rebut: order is undefined, concurrent_futures specifies map() returns an 
iterator, where builtin map returns a list. 
Q: Does it break the spirit of the module?
A: No, I believe one of the best things about doing things async is the 
dataflow model: do the next thing as soon as its inputs are ready.
 Q: Should we hold up the caller in all cases when there are stragglers, i.e. 
elements that compute slower?
 A: No, the interface should allow both modes.

def james_map(exe, fn, *args):
  return iter( sorted( list( exe.map( fn, *args ) ) ) )

--
messages: 260396
nosy: F.D. Sacerdoti
priority: normal
severity: normal
status: open
title: concurrent_futures Executor.map semantics better specified in docs
type: enhancement
versions: Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com