[Python-Dev] PEP 3148 ready for pronouncement

[Brian Quinlan]

On May 26, 2010, at 8:57 PM, Greg Ewing wrote:

> Having read through the PEP again, here are my thoughts.
>
> * I'm bothered by the term "future". To my mind, it's
> too long on cleverness and too short on explanativeness.
>
> I think that the standard library is no place for
> cuteness of naming. The name of a stdlib module should
> reflect its functionality in some straightforward and
> obvious way. If I were looking for a thread pool or
> process pool implementation, the word "future" is not
> something that would spring readily to mind.
>
> The stated purpose of the module is to "execute
> computations asynchronously", so perhaps a name such
> as "asyntask" would be appropriate, following the
> pattern of existing modules dealing with ansynchronous
> matters, ansyncore and asynchat. For the Future object
> itself, I'd suggest something like "Task" or "Job".

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

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

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

> (More generally, I'm inclined to think that introducing
> a namespace package for a category of modules having
> existing members in the stdlib is an anti-pattern,
> unless it's done during the kind of namespace refactoring
> that we won't get another chance to perform until Py4k.)
>
> Concerning the structure of the PEP:
>
> * A section titled 'Specification' should *not* start
> with a bunch of examples. It may be appropriate to include
> short examples *following* items in the specification in
> order to illustrate the features concerned. Extended
> examples such as these belong in a section of their own.

I thought that the specification would be difficult to follow without  
examples to pave the way. Anyone else have an opinion on this?

> * I found the examples included to be rather difficult
> to follow, and they served more to confuse than elucidate.
> I think this is partly because they are written in a
> fairly compressed style, burying important things being
> illustrated inside complicated expressions. Rewriting
> them in a more straightforward style might help.

Do you think starting with a simpler example would help? I think that  
idiomatic future use will end up looking similar to my examples. If  
that is too complex for most users then we have a problem.

> Concerning details of the specification:
>
> * Is it possible to have more than one Executor active
> at a time?

Of course.

> The fact that as_completed() is a module-level
> function rather than an Executor method suggests that it
> is, but it would be good to have this spelled out one
> way or the other in the PEP.

I'll add a note to the global functions that they can accept futures  
from different in the same call.

Cheers,
Brian

>
> -- 
> Greg
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/brian%40sweetapp.com