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

[Eric Snow]

On Wed, Nov 16, 2011 at 8:08 AM, PJ Eby <pje at telecommunity.com> wrote:
> On Wed, Nov 16, 2011 at 1:29 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>> So, without a clear answer to the question of "from module X, inside
>> package (or package portion) Y, find the nearest parent directory that
>> should be placed on sys.path" in a PEP 402 based world, I'm switching
>> to supporting PEP 382 as my preferred approach to namespace packages.
>> In this case, I think "explicit is better than implicit" means, "given
>> only a filesystem hierarchy, you should be able to figure out the
>> Python package hierarchy it contains". Only explicit markers (either
>> files or extensions) let you do that - with PEP 402, the filesystem
>> doesn't contain enough information to figure it out, you need to also
>> know the contents of sys.path.
>
> After spending an hour or so reading through PEP 395 and trying to grok what
> it's doing, I actually come to the opposite conclusion: that PEP 395 is
> violating the ZofP by both guessing, and not encouraging One Obvious Way of
> invoking scripts-as-modules.
> For example, if somebody adds an __init__.py to their project directory,
> suddenly scripts that worked before will behave differently under PEP 395,
> creating a strange bit of "spooky action at a distance".  (And yes, people
> add __init__.py files to their projects in odd places -- being setuptools
> maintainer, you get to see a LOT of weird looking project layouts.)
> While I think the __qname__ idea is fine, and it'd be good to have a way to
> avoid aliasing main (suggestion for how included below), I think that
> relative imports failing from inside a main module should offer an error
> message suggesting you use "-m" if you're running a script that's within a
> package, since that's the One Obvious Way of running a script that's also a
> module.  (Albeit not obvious unless you're Dutch.  ;-) )
> For the import aliasing case, AFAICT it's only about cases where __name__ ==
> '__main__', no?  Why not just save the file/importer used for __main__, and
> then have the import machinery check whether a module being imported is
> about to alias __main__?  For that, you don't need to know in *advance* what
> the qualified name of __main__ is - you just spot it the first time somebody
> re-imports it.
> I think removing qname-quessing from PEP 395 (and replacing it with
> instructive/google-able error messages) would be an unqualified improvement,
> independent of what happens to PEPs 382 and 402.

But which is more astonishing (POLA and all that): running your module
in Python, it behaves differently than when you import it (especially
__name__); or you add an __init__.py to a directory and your *scripts*
there start to behave differently?

When I was learning Python, it took quite a while before I realized
that modules are imported and scripts are passed at the commandline;
and to understand the whole __main__ thing.  It has always been a
pain, particularly when I wanted to
 just check a module really quickly for errors.

However, lately I've actually taken to the idea that it's better to
write a test script that imports the module and running that, rather
than running the module itself.  But that came with the understanding
that the module doesn't go through the import machinery when you *run*
it, which I don't think is obvious, particularly to beginners.  So
Nick's solution, to me, is an appropriate concession to the reality
that most folks will expect Python to treat their modules like modules
and their scripts like scripts.

Still, this actually got me wishing there were a way to customize
script-running the same way you can customize import with __import__
and import hooks.

-eric


>
> _______________________________________________
> Import-SIG mailing list
> Import-SIG at python.org
> http://mail.python.org/mailman/listinfo/import-sig
>
>