On Wed, Jul 20, 2011 at 11:56 AM, Jeff Hardy <jdha...@gmail.com> wrote: > On Tue, Jul 19, 2011 at 8:58 PM, P.J. Eby <p...@telecommunity.com> wrote: >> The biggest likely exception to the above would be when a piece of >> code tries to check whether some package is installed by importing >> it. If this is done *only* by importing a top-level module (i.e., not >> checking for a ``__version__`` or some other attribute), *and* there >> is a directory of the same name as the sought-for package on >> ``sys.path`` somewhere, *and* the package is not actually installed, >> then such code could *perhaps* be fooled into thinking a package is >> installed that really isn't. > > This part worries me slightly. Imagine a program as such: > > datagen.py > json/foo.js > json/bar.js > > datagen.py uses the files in json/ to generate sample data for a > database. In datagen.py is the following code: > > try: > import json > except ImportError: > import simplejson as json > > Currently, this works just fine, but if will break (as I understand > it) under the PEP because the json directory will become a virtual > package and no ImportError will be raised. Is there a mitigation for > this in the PEP that I've missed?
This problem was brought up a few times on import-sig, but I don't think a solution was ever decided on. The best solution I can think of would be to have a way for a module to mark itself as "finalized" (I'm not sure if that's the best term--just the first that popped into my head). This would prevent its __path__ from being created or extended in any way. For example, if the json module contains `__finalized__ = True` or something of the like, any `import json.foo` would immediately fail. Of course, this would put all the onus on the json module to solve this problem, and other modules might actually wish to be extendable into packages, in which case you'd still have this problem. In that case there would need to be a way to mark a directory as not containing importable code. Not sure what the best approach to that would be, especially since one of the goals of this PEP seems to be to avoid marker files. Erik _______________________________________________ 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
