[Python-3000] The main module in Py3k

[Nick Coghlan]

Guido van Rossum wrote:
> \On 7/4/06, Giovanni Bajo <rasky at develer.com> wrote:
>> Guido van Rossum wrote:
>>
>>>> Relative imports from modules executed with -m, however, would now
>>>> be able to use the normal relative import mechanism and the
>>>> __module_name__ workaround proposed for the 2.x series could
>>>> disappear.
>>> Frankly, I am beginning to regret ever having endorsed the -m option.
>> In case you mean the -m pkg.mod spelling, I agree. It's bringing a lot of
>> complexity, including the __module_name__ hack, for exactly what gain? So
>> that one doesn't have to write 2 liner wrapper installed as top-level module
>> in the site-packages?

The original -m switch was added so that it was possible to easily run utility 
modules (like pdb, timeit, profile, etc):
   1. without the user needing to care about how the current Python 
installation is laid out on the filesystem
   2. without module developers needing to worry about namespace conflicts 
with other applications on the system path

On any Python 2.4 system, the following runs a script:
   python script.py

And the following profiles it:
   python -m profile script.py

Before 2.4, you had to figure out the path to the utility module before you 
could run it:

C:\>python -c "import profile; print profile.__file__"
c:\python24\lib\profile.pyc

C:\>python c:/python24/lib/profile.py script.py

The second command was not only *platform* dependent, but potentially even 
*machine* dependent, if the standard library was in an unusual location.

PEP 338 expanded the -m switch to packages so that:
   1. packages could be used to avoid namespace conflicts for utility modules 
as well as support modules
   2. utility modules could benefit from the file system independence provided 
by PEP 302

For example, 2.5 makes it trivial to run pychecker over a script:
   python -m pychecker.checker script.py

Before 2.5, you had to figure out the filename as for the top level utility 
module example above. And if it turned out the answer referred to a module 
stored in a zip file, or if you only had a .pyc file (without the source 
file), then you were fresh out of luck - even though the Python interpreter 
knew exactly where to find the script, how to extract it, and how to run it, 
it didn't provide any way to run it as the main module (because the main 
module had to be a real source file).

As far as the question of allowing relative imports from a main module goes, 
they're useful for exactly the same reason that relative imports are useful 
from *any* module that forms part of a package: it allows the entire package 
to be relocated to a different part of the module namespace without requiring 
any changes to the modules inside the package. If you use absolute imports, 
then changing the name of the package, or moving it inside another package, 
requires touching every single module in the package in order to update the 
import statements.

> And by extension even the -m mod spelling, since its introduction led
> to the argument that -m pkg.mod should not be left behind...

The genesis of this really lies in PEPs 273 and 302 and the difficulty of 
locating the different parts of the Python standard library on the filesystem. 
The key thing about the implementation of those two PEPs is that they are what 
originally broke the previously straightforward mapping between the file 
system directory structure and the package namespace structure. They provided 
a *lot* of flexibility in packaging Python applications, but were unable to 
help with packaging of the main module of the application.

The -m switch was really just a small extension to allow this idea of 
filesystem independence to be applied to the main module as well as support 
modules. If filesystem independence is a bad thing, then PEPs 273 and 302 
should never have been accepted. If file system independence is a good thing, 
then the main module shouldn't be treated as a second class citizen.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org