...

Guido van Rossum writes: Code that *doesn't* need Queue but does use threading shouldn't have to pay for loading Queue.py.

Greg Ewing responds:

...

What we want in this kind of situation is some sort of autoloading mechanism, so you can import something from a module and have it trigger the loading of another module behind the scenes to provide it.

John Camera comments:

...

Bad idea unless it is tied to a namespace. So that users knows where this auto-loaded functionality is coming from. Otherwise it's just as bad as 'from xxx import *'.

Michael Chermside comments: John, I think what Greg is suggesting is that we include Queue in the threading module, but that we use a Clever Trick(TM) to address Guido's point by not actually loading the Queue code until the first time (if ever) that it is used.

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 guess from Greg’s comments I’m not sure if he wants to import threading and as a result ‘Queue’ becomes available in the local namespace and bound/loaded when it is first needed and thus saves himself from typing ‘import Queue’ immediately after ‘import threading’ or Queue becomes part of the threading namespace and bound/loaded when it is first needed. Queue then becomes accessible through ‘threading.Queue’ When Greg says

However, it does seem awkward to have a whole module providing just one small class that logically is so closely related to other threading facilities.

It sounds like he feels Queue should just be part of threading but queues can be used in other contexts besides threading. So having separate modules is a good thing. The idea of delaying an import until it’s needed sounds like a great idea and having built in support for this would be great. Here are 2 possible suggestions for the import statements import Queue asneeded delayedimport Queue # can't think of a better name at this time But auto loading a module by a module on behalf of a client just doesn’t sit too well for me. How about the confusion it would cause. Is Queue in treading module a reference to a Queue in a Queue module or a new class all together? If we go down this slippery slope we will see modules like array, struct, etc getting referenced and getting auto loaded on behalf of the client. Where will it end. John M. Camara

...

Guido van Rossum writes: Code that *doesn't* need Queue but does use threading shouldn't have to pay for loading Queue.py.

Greg Ewing responds:

...

What we want in this kind of situation is some sort of autoloading mechanism, so you can import something from a module and have it trigger the loading of another module behind the scenes to provide it.

John Camera comments:

...

Bad idea unless it is tied to a namespace. So that users knows where this auto-loaded functionality is coming from. Otherwise it's just as bad as 'from xxx import *'.

John, I think what Greg is suggesting is that we include Queue in the threading module, but that we use a Clever Trick(TM) to address Guido's point by not actually loading the Queue code until the first time (if ever) that it is used.

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.

-- Michael Chermside