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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com