[Python-Dev] PEP 3148 ready for pronouncement

[Brian Quinlan]

On May 21, 2010, at 9:47 PM, John Arbash Meinel wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Brian Quinlan wrote:
>> The PEP is here:
>> http://www.python.org/dev/peps/pep-3148/
>>
>> I think the PEP is ready for pronouncement, and the code is pretty  
>> much
>> ready for submission into py3k (I will have to make some minor  
>> changes
>> in the patch like changing the copyright assignment):
>> http://code.google.com/p/pythonfutures/source/browse/#svn/branches/ 
>> feedback/python3/futures%3Fstate%3Dclosed
>>
>> The tests are here and pass on W2K, Mac OS X and Linux:
>> http://code.google.com/p/pythonfutures/source/browse/branches/feedback/python3/test_futures.py
>>
>> The docs (which also need some minor changes) are here:
>> http://code.google.com/p/pythonfutures/source/browse/branches/feedback/docs/index.rst
>>
>> Cheers,
>> Brian
>>
>
> I also just noticed that your example uses:
> zip(PRIMES, executor.map(is_prime, PRIMES))
>
> But your doc explicitly says:
> map(func, *iterables, timeout=None)
>
>    Equivalent to map(func, *iterables) but executed asynchronously and
> possibly out-of-order.
>
> So it isn't safe to zip() against something that can return out of  
> order.

The docs don't say that the return value can be out-of-order, just  
that execution can be out-of-order. But I agree that the phrasing is  
confusing so I've changed it to:

     Equivalent to ``map(func, *iterables)`` but *func* is executed
     asynchronously and several calls to *func *may be made  
concurrently.


> Which opens up a discussion about how these things should be used.

Except that now isn't the time for that discussion. This PEP has  
discussed on-and-off for several months on both stdlib-sig and python- 
dev.

If you think that storing the args (e.g. with the future) is a good  
idea then you can propose a patch after the PEP is integrated (if it  
is rejected then it probably isn't worth discussing ;-)).

Cheers,
Brian

> Given that your other example uses a dict to get back to the original
> arguments, and this example uses zip() [incorrectly], it seems that  
> the
> Futures object should have the arguments easily accessible. It  
> certainly
> seems like a common use case that if things are going to be returned  
> in
> arbitrary order, you'll want an easy way to distinguish which one you
> have.  Having to write a dict map before each call can be done, but
> seems unoptimal.
>
> John
> =:->
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (Cygwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkv2cugACgkQJdeBCYSNAAPWzACdE6KepgEmjwhCD1M4bSSVrI97
> NIYAn1z5U3CJqZnBSn5XgQ/DyLvcKtbf
> =TKO7
> -----END PGP SIGNATURE-----