[Python-Dev] PEP 3148 ready for pronouncement (original) (raw)

Brian Quinlan brian at sweetapp.com
Wed May 26 13:05:45 CEST 2010

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 ascompleted() 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

More information about the Python-Dev mailing list