[Python-Dev] PEP 3148 ready for pronouncement
Brian Quinlan
brian at sweetapp.com
Fri May 21 14:26:13 CEST 2010
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-----
More information about the Python-Dev
mailing list