[Python-Dev] PEP 3148 ready for pronouncement
John Arbash Meinel
john.meinel at canonical.com
Fri May 21 13:47:52 CEST 2010
-----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.
Which opens up a discussion about how these things should be used.
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