[Python-Dev] PEP 3148 ready for pronouncement
Steve Holden
steve at holdenweb.com
Sat May 29 02:16:04 CEST 2010
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
More information about the Python-Dev
mailing list