On Wed, Oct 12, 2005, Greg Ewing wrote: > Guido van Rossum wrote: >> >> I see no need. Code that *doesn't* need Queue but does use threading >> shouldn't have to pay for loading Queue.py. I'd argue that such code is rare enough (given the current emphasis on Queue) that the performance issue doesn't matter. > 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. The problem is that historically Queue did not use ``threading``; it was built directly on top of ``thread``, and people were told to use Queue regardless of whether they were using ``thread`` or ``threading``. Obviously, there is no use case for putting Queue into ``thread``, so off it went into its own module. At this point, my opinion is that we should leave reorganizing the thread stuff until Python 3.0. (Python 3.0 should "deprecate" ``thread`` by renaming it to ``_thread``). -- Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/ "If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." --Red Adair
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4