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-----
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4