[Import-SIG] PEP 395 (Module aliasing) and the namespace PEPs

[PJ Eby]

On Wed, Nov 16, 2011 at 5:41 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> If the package directory markers are explicit (as they are now and as
> they are in PEP 382), then PEP 395 isn't guessing - the mapping from
> the filesystem layout to the Python module namespace is completely
> unambiguous, since the directory added as sys.path[0] will always be
> the first parent directory that isn't marked as a package directory:
>

Sorry, but that's *still guessing*.  Random extraneous __init__.py and
subdirectories on sys.path can screw you over.  For example, if I have a
stray __init__.py in site-packages, does that mean that every module there
is a submodule of a package called 'site-packages'?

Sure, you could fix that problem by ignoring names with a '-', but that's
just an illustration.  The __init__.py idea was a very good attempt at
solving the problem, but even in today's Python, it's still ambiguous and
we should refuse to guess.  (Because it will result in weird behavior
that's *much* harder to debug.)

Import aliasing detection and relative import errors, on the other hand,
don't rely on guessing.


Even if the "just do what I mean" part of the proposal in PEP 395 is
> replaced by a "Did you mean?" error message, PEP 382 still offers the
> superior user experience, since we could use runpy.split_path_module()
> to state the *exact* argument to -m that should have been used.


No, what you get is just a *guess* as to the correct directory.  (And you
can make similar guesses under PEP 402, if a parent directory of the script
is already on sys.path.)



> Of
> course, that still wouldn't get sys.path[0] set correctly, so it isn't
> a given that it would really help.
>

Right; and if you already *have* a correct sys.path, then you can make just
as good a guess under PEP 402.

Don't get me wrong - I'm all in favor of further confusion-reduction (which
is what PEP 402's about, after all).  I'm just concerned that PEP 395 isn't
really clear about the tradeoffs, in the same way that PEP 382 was unclear
back when I started doing all those proposed revisions leading up to PEP
402.

That is, like early PEP 382, ISTM that it's an initial implementation
attempt to solve a problem by patching over it, rather than an attempt to
think through "how things are" and "how they ought to be".  I think some of
that sort of thinking ought to be done, to see if perhaps there's a better
tradeoff to be had.

For one thing, I wonder about the whole scripts-as-modules thing.  In other
scripting languages AFAICT it's not very common to have a script as a
module; there's a pretty clear delineation between the two, because
Python's about the only language with the name==main paradigm.  In
languages that have some sort of "main" paradigm, it's usually a specially
named function or class method (Java) or whatever.

So, I'm wondering a bit about the detailed use cases people have about
using modules as scripts and vice versa.  Are they writing scripts, then
turning them into modules?  Trying to run somebody else's modules?  Copying
example code from somewhere?

(The part that confuses me is, if you *know* there's a difference between a
script and a module, then presumably you either know about __name__, OR you
wouldn't have any reason to run your module as a script.  Conversely, if
you don't know about __name__, then how would you conceive of making your
script into a module?  ISTM that in order to even have this problem you
have to at least be knowledgeable enough to realize there's *some*
difference between moduleness and scriptness.)

Anyway, understanding the *details* of this process (of how people end up
making the sort of errors PEP 395 aims to address) seems important to me
for pinning down precisely what problem to solve and how.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/import-sig/attachments/20111116/d63d7537/attachment.html>