[Python-Dev] PEP 3148 ready for pronouncement

[John Arbash Meinel]

-----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-----