On 10 November 2010 04:12, Stephen J. Turnbull <step...@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 can't think of stdlib examples, but for 3rd party packages I'd say storm.locals and fabric.api are examples of packages designed with "from foo import * " in mind. So this does happen. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
