[Python-Dev] PEP 3148 ready for pronouncement (original) (raw)

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/testfutures.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