-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/09/2010 11:12 PM, Stephen J. Turnbull 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.
Right -- "private" star imports aren't the issue for me, because the same user who creates them is responsible for the other end fo the stick. I was ranting about library authors who document star imports as the expected usage pattern for their external users. Note that I still wouldn't use star imports in the "private acceleration" case myself. I would prefer a pattern like: - ----------------------- $< ----------------------------- # spam.py # Pure python API implementation def foo(spat, blarg): ... def bar(qux): ... # Replace with accelearated C implemenataion try: import _spam except ImportError: pass # accelerated version not available else: foo = _spam.foo bar = _spam.bar - ----------------------- $< ----------------------------- This explicit name remapping catches unintentional erros (e.g., _spam renames a method) better than the star import. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzazykACgkQ+gerLs4ltQ5BHACfaAh2lVLZ8C+mdV/88UJ0JXTo sqQAn2b2J9cZSQuz2xrwZX/JrvY3AaMh =EIDa -----END PGP SIGNATURE----- _______________________________________________ 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