[Python-3000] PEP to change how the main module is delineated

[Steven Bethard]

On 4/23/07, Brett Cannon <brett at python.org> wrote:
> On 4/22/07, Steven Bethard <steven.bethard at gmail.com> wrote:
> > On 4/22/07, Brett Cannon <brett at python.org> wrote:
> > > Implementation
> > > ==============
> > >
> > > When the ``-m`` option is used, ``sys.main`` will be set to the
> > > argument passed in.  ``sys.argv`` will be adjusted as it is currently.
> > > Then the equivalent of ``__import__(self.main)`` will occur.  This
> > > differs from current semantics as the ``runpy`` module fetches the
> > > code object for the file specified by the module name in order to
> > > explicitly set ``__name__`` and other attributes.  This is no longer
> > > needed as import can perform its normal operation in this situation.
> > >
> > > If a file name is specified, then ``sys.main`` will be set to
> > > ``"__main__"``.  The specified file will then be read and have a code
> > > object created and then be executed with ``__name__`` set to
> > > ``"__main__"``.  This mirrors current semantics.
[snip]
> > If that's right, I'm -1 on the proposal. It's complicating the
> > standard "am I the main module?" idiom to solve a tiny little problem
> > with "-m".
>
> It's not a '-m' problem, it's a relative import problem.

Right, but the PEP was only solving the relative import problem for '-m'.

> > Two reasons that would be compelling for me:
> >
> > * Simplifying the "am I the main module?" idiom, e.g. with the
> > rejected ``if __main__`` proposal.
> >
> > * Getting rid of the "__main__" value for __name__ entirely. This
> > would require code like the following to determine the name of a
> > module given at the command line::
[snip]
> >   Even if we can't do the name resolution perfectly, if the flaws are
> > documented (e.g. when '..' and symbolic links are combined) I think
> > that would be enough better than the current situation to merit
> > changing the standard "am I the current module?" idiom.
>
> As I said in the PEP, I rejected this because of startup cost.  If
> people are willing to pay for it then we can go with it

I'm personally willing to pay for it because it's only going to apply
at most once each time ``python`` is started.

> So the questions for people to weigh in on are:

I'm basically +1 on all the versions that do the full lookup. That
means scanning up the parent directories until we encounter either a
directory with no __init__.py or a directory on sys.path.

> * For spam/bacon.py w/ with spam/__init__.py existing:

Infer 'spam.bacon':
* parent dir of 'bacon.py', 'spam', has an '__init__.py', so 'spam.bacon'
* parent dir of 'spam' is on sys.path (it's the current directory), so stop

> * For spam/bacon.py with *no* spam/__init__.py:

Infer 'bacon':
* parent dir of 'bacon.py' has no '__init__.py', so stop

> * For ../bacon.py
>
>    - With ../__init__.py defined and ../../ on sys.path:

Infer 'spam.bacon' (assuming parent directory is 'spam'):
* parent dir of 'bacon.py', 'spam', has an '__init__.py', so 'spam.bacon'
* parent dir of 'spam' is on sys.path, so stop

>    - Without ../__init__.py

Infer 'bacon'
* parent dir of 'bacon.py' has no '__init__.py', so stop.

The above were pretty easy. Here's a harder one:

    foo/
      __init__.py
      bar/
        __init__.py
        baz/
          __init__.py
          frobble.py

where the 'foo' directory is on sys.path. Should this infer
'bar.baz.frobble' or 'foo.bar.baz.frobble'?  The former assumes that
sys.path takes precedence over the presence of an '__init__.py'.  The
latter assumes the reverse.  (I lean towards the fomer FWIW, though it
might be worth giving the person who organized their code this way
some sort of bodily threat.) ;-)

> If people want a simple inference rule we can ditch __main__ entirely
> and just go with a simple rule that would be more costly for startup.

This is my preference, but I guess I'd like to know how big the
startup costs would be. Clearly if Python takes twice as long to
start, it's not worth it. ;-)

STeVe
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
        --- Bucky Katt, Get Fuzzy