[Python-Dev] PEP 3148 ready for pronouncement

[Greg Ewing]

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