On 24/01/2013 16:53, Oscar Benjamin wrote: >> Does it work if you use the -m option to run a module rather than a script? > > Sorry that was written incorrectly. I meant to say: does it work when > a module is directly on sys.path rather than as a submodule of a > package? In this case __package__ is set to the empty string if run > with -m or None if run with a direct path. So the check needs to be > "__package__ is not None" rather than "bool(__package__)".
The answer is: it depends. Given the code I outlined earlier: A package-based module run via -m (python -m package.module) works as described (including the implicit __main__ module, my primary use-case). A module run from the filesystem (python c:\path\to\module.py) works by dropping through through to the not is_package logic branch. A module run via -m (python -m module) actually works by accident, because it too drops through to the not is_package branch and is rerun with its full filesystem path. This doesn't have the same problems as running a package from the filesystem because relative imports aren't an issue. I don't know if there are any other differences between python -mmodule and python c:\path\to\module.py. As you say, a more refined check could determine a blank __package__ as opposed to a None __package__. But this code (cherrypy) must also cope with version of Python before 2.6 which didn't even have a __package__ attribute, muddying the waters that little bit further. TJG -- http://mail.python.org/mailman/listinfo/python-list
