On May 26, 2010, at 8:57 PM, Greg Ewing wrote: > Having read through the PEP again, here are my thoughts. > > * I'm bothered by the term "future". To my mind, it's > too long on cleverness and too short on explanativeness. > > I think that the standard library is no place for > cuteness of naming. The name of a stdlib module should > reflect its functionality in some straightforward and > obvious way. If I were looking for a thread pool or > process pool implementation, the word "future" is not > something that would spring readily to mind. > > The stated purpose of the module is to "execute > computations asynchronously", so perhaps a name such > as "asyntask" would be appropriate, following the > pattern of existing modules dealing with ansynchronous > matters, ansyncore and asynchat. For the Future object > itself, I'd suggest something like "Task" or "Job". "future" is a computing science term of art, like "thread". Anyway, this has been discussed in the past and Guido was happy with the name. > * It seems unnecessarily verbose to tack "Executor" > onto the end of every Executor subclass. They could > simply be called ThreadPool and ProcessPool without > losing anything. You could have general thread pools that aren't related to executors (actually, it would be great if Python had a good built-in thread pool implementation) and I'd like to avoid using an overly generic name. > * I don't see a strong reason to put this module > inside a newly-created namespace. If there were a > namespace called "concurrent", I would expect to find > other existing concurrency-related modules there as > well, such as threading and multiprocessing. But we > can't move them there without breaking existing code. I think that Jesse was planning to add some functionality to this namespace. I don't really have an opinion on this. > (More generally, I'm inclined to think that introducing > a namespace package for a category of modules having > existing members in the stdlib is an anti-pattern, > unless it's done during the kind of namespace refactoring > that we won't get another chance to perform until Py4k.) > > Concerning the structure of the PEP: > > * A section titled 'Specification' should *not* start > with a bunch of examples. It may be appropriate to include > short examples *following* items in the specification in > order to illustrate the features concerned. Extended > examples such as these belong in a section of their own. I thought that the specification would be difficult to follow without examples to pave the way. Anyone else have an opinion on this? > * I found the examples included to be rather difficult > to follow, and they served more to confuse than elucidate. > I think this is partly because they are written in a > fairly compressed style, burying important things being > illustrated inside complicated expressions. Rewriting > them in a more straightforward style might help. Do you think starting with a simpler example would help? I think that idiomatic future use will end up looking similar to my examples. If that is too complex for most users then we have a problem. > Concerning details of the specification: > > * Is it possible to have more than one Executor active > at a time? Of course. > The fact that as_completed() is a module-level > function rather than an Executor method suggests that it > is, but it would be good to have this spelled out one > way or the other in the PEP. I'll add a note to the global functions that they can accept futures from different in the same call. Cheers, Brian > > -- > Greg > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/brian%40sweetapp.com
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