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

Vinay Sajip vinay_sajip at yahoo.co.uk
Sat May 29 00:28:46 CEST 2010

Brian Quinlan <brian sweetapp.com> writes:

"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.

I've not seen this mentioned, but on such a long thread I might have missed it: we already have a "future" module, as in

from future import with_statement

and to my mind, this is a potential point of confusion with the term "future".

> * 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.

Aren't executors and pools both housekeepers around a bunch of threads which execute code as a service for other threads? A thread is useless unless it executes code, isn't it? I'm not sure I understand the fine distinction between an executor and a pool. Having Executor as a suffix will give a point of familiarity to those who already know java.util.concurrent. And ProcessPool might cause confusion with multiprocessing.Pool because at first glance they seem to be the same thing.

> * 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.

I'm not sure of the benefit of a "concurrent" namespace, since it wouldn't contain the existing concurrency stuff. I think it's something to consider only for a big reorg which would break backward compatibility. IMO it would make more sense to leave this module as a top-level module for now (a sibling to "threading", "multiprocessing").

Regards,

Vinay Sajip

More information about the Python-Dev mailing list