On 10/12/05, Michael Chermside <[EMAIL PROTECTED]> wrote:
> I'm not familiar with the clever trick Greg is proposing, but I
> do agree that _IF_ everything else were equal, then Queue seems
> to belong in the threading module. My biggest reason is that I
> think anyone who is new to threading probably shouldn't use any
> communication mechanism OTHER than Queue or something similar
> which has been carefully designed by someone knowlegable.

I *still* disagree. At some level, Queue is just an application of
threading, while the threading module provides the basic API (never
mind that there's an even more basic API, the thread module -- it's
too low-level to consider and we actively recommend against it, at
least I hope we do).

While at this point there may be no other "applications" of threading
in the standard library, that may not remain the case; it's quite
possble that some of the discussions of threading APIs will eventually
lead to a PEP proposing a different threading paradigm build on top of
the threading module.

 I'm using the word "application" loosely here because I realize one
person's application is another's primitive operation. But I object to
the idea that just because A and B are often used together or A is
recommended for programs using B that A and B should live in the same
module. We don't put urllib and httplib in the socket module either!

Now, if we had a package structure, I would sure like to see threading
and Queue end up as neighbors in the same package. But I don't think
it's right to package them all up in the same module.

(Not to say that autoloading is a bad idea; I'm -0 on it for myself,
but I can see use cases; but it doesn't change my mind on whether
Queue should become threading.Queue. I guess I didn't articulate my
reasoning for being against that well previously and tried to hide
behind the load time argument.)

BTW, Queue.Queue violates a recent module naming standard; it is now
considered bad style to name the class and the module the same.
Modules and packages should have short all-lowercase names, classes
should be CapWords. Even the same but different case is bad style.
(I'd suggest queueing.Queue except nobody can type that right. :)

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
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

Reply via email to