[Fredrik Lundh] > Brett Cannon wrote: > > > > > > > > try: > > > > > > import threading > > > > > > except ImportError: > > > > > > threading = None # use non-threaded behaviour > > > But if it does it will be on platforms it couldn't run on previously. > > Sigh. Let's try one more time: > > Under 2.2 and earlier, on a platform that doesn't support threads, > the above code will set threading to None, and the application can > then use "if threading is None" to provide application-specific work- > arounds. > I get this and always have. I just have not thought of it as huge of an issue as you do. If it is that big of a worry, add a ``import thread; del thread`` statement to make sure ``thread`` is there and warn users not to use the code. But I know you are going to be against the idea of modifying existing code for this, so I am going to let it go. Your point is valid, we just differ on its importance. Is Guido's suggested ``dummy_threading`` okay with you? > (catching import errors is a very common pattern when you're writing > portable Python code). > I know, I use it myself. > If you change Python so that "import threading" succeeds also on plat- > forms that don't support threads, the application-specific workarounds > will no longer be used, and the application may no longer work properly. > > And since we're talking deadlocks, chances are that nobody will notice > before it's too late. > OK, I am going to concede on this and stop pushing for it. Let me know what you think of Guido's ``dummy_threading`` idea. I assume you don't object to changing ``Queue``, though, right? -Brett
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