[Python-Dev] Autoloading? (Making Queue.Queue easier to use)

[Michael Chermside]

John Camera writes:
> 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.

Perhaps I am wrong here, but the Queue.Queue class is designed specifically
for synchronization, and I have always been under the impression that
it was probably NOT the best tool for normal queues that have nothing
to do with threading. Why incur the overhead of synchronization locks
when you don't intend to use them. I would advise against using Queue.Queue
in any context besides threading.

continued...
> I guess from Greg’s comments I’m not sure if he wants to [...]

I'm going to stop trying to channel Greg here, he can speak for himself.
But I will be quite surprised if _anyone_ supports the idea of having
an module modify the local namespace importing it when it is imported.

and later...
> Here are 2 possible suggestions for the import statements
>
> import Queue asneeded
> delayedimport Queue     # can't think of a better name at this time


Woah! There is no need for new syntax here! If you want to import
Queue only when needed use this (currently legal) syntax:

    if queueIsNeeded:
        import Queue

If you want to add a module (call it "Queue") to the namespace, but
delay executing some of the code for now, then just use "import Queue"
and modify the module so that it doesn't do all its work at import
time, but delays some of it until needed. That too is possible today:

    # start of module
    initialized = False

    def doSomething():
        if not initialized:
            initialize()

    # ...

Python today is incredibly dynamic and flexible... despite the usual
tenor of conversations on python-dev, it is very rare to encounter a
problem that cannot be solved (and readably so) using the existing
tools and constructs.

-- Michael Chermside