[Python-Dev] PEP 3148 ready for pronouncement

[Vinay Sajip]

Brian Quinlan <brian <at> 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