[Python-Dev] PEP 3148 ready for pronouncement

[Steve Holden]

Vinay Sajip wrote:
> 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").
> 
Unless there's some way of having the two namespaces (existing and
concurrent-oriented) simultaneously coexist. A single implementation
with two separate namespace mappings?

regards
 Steve
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
See Python Video!       http://python.mirocommunity.org/
Holden Web LLC                 http://www.holdenweb.com/
UPCOMING EVENTS:        http://holdenweb.eventbrite.com/
"All I want for my birthday is another birthday" -
                                     Ian Dury, 1942-2000