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@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/brian%40sweetapp.com
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
