On Wed, 10 Nov 2010 13:12:09 +0900, "Stephen J. Turnbull" <stephen at xemacs.org> wrote: > Nick Coghlan writes: > > > > Module writers who compound the error by expecting to be imported > > > this way, thereby bogarting the global namespace for their own > > > purposes, should be fish-slapped. ;) > > > > Be prepared to fish-slap all of python-dev then - we use precisely > > this technique to support optional acceleration modules. The pure > > Python versions of pairs like profile/_profile and heapq/_heapq > > include a try/except block at the end that does the equivalent of: > > > > try: > > from _accelerated import * # Allow accelerated overrides > > except ImportError: > > pass # Use pure Python versions > > But these identifiers will appear at the module level, not global, no? > Otherwise this technique couldn't be used. I don't really understand > what Tres is talking about when he writes "modules that expect to be > imported this way". The *imported* module shouldn't care, no? This > is an issue for the *importing* code to deal with. I think Tres was referring to certain packages (which shall remain nameless since I don't feel like googling to find one) whose documentation recommends the 'from <me> import *' methodology. At least that's how I read "Module writers who..." (that is, he's not saying the *module* expects to be imported that way). [*] -- R. David Murray www.bitdance.com [*] although reading that sentence literally, the thought of such a module writer themselves being imported that way (a la Tron) has a certain charm....
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