[Python-Dev] PEP 3148 ready for pronouncement (original) (raw)
Greg Ewing greg.ewing at canterbury.ac.nz
Wed May 26 12:57:15 CEST 2010
- Previous message: [Python-Dev] PEP 3148 ready for pronouncement
- Next message: [Python-Dev] PEP 3148 ready for pronouncement
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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".
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.
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.
(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 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.
Concerning details of the specification:
- Is it possible to have more than one Executor active at a time? 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.
-- Greg
- Previous message: [Python-Dev] PEP 3148 ready for pronouncement
- Next message: [Python-Dev] PEP 3148 ready for pronouncement
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]