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

PJ Eby pje at telecommunity.com
Thu Nov 17 03:00:20 CET 2011

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

> On Thu, Nov 17, 2011 at 10:10 AM, PJ Eby <pje at telecommunity.com> wrote:
> > 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.
> The module->script process comes from wanting to expose useful command
> line functionality from a Python module in a cross-platform way
> without any additional packaging effort (as exposing system-native
> scripts is a decidedly *non* trivial task, and also doesn't work from
> a source checkout).

No, I mean how do the people who PEP 395 is supposed to be helping, find
out that they even want to run a script as a module?

Or are you saying that the central use case the PEP is aimed at is running
stdlib modules?  ;-)

> It's also fairly common for test definition modules to support
> execution via "-m" (by invoking unittest.main() from an "if __name__"
> guarded suite).

Right...  so are these modules not *documented* as being run by -m?  Are
people running them as scripts by mistake?

I'm still not seeing how people end up making their own scripts into
modules or  vice versa, *without* some explicit documentation about the
process.  I mean, how do you even know that a file can be both, without
realizing that there's a difference between the two?

The most common confusion I've seen among newbies is the ones who don't
grok that module != file.  That is, they don't understand why you replace
directory separators with '.' (which is how they think of it) or they want
to use exec/runfile instead of import, or they expect import to run the
code, or similar confusions of "file" and "module".

However, I don't grok how people with *that* confusion would end up writing
code that has a problem when run as a combination script/module, because
they already think scripts and modules are the same thing and are rather
unlikely to create a package in the first place.

So who *is* PEP 395's target audience, and what is their mental model?
 That's the question I'd like to come to grips with before proposing a full
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/import-sig/attachments/20111116/5c81ffcf/attachment.html>

More information about the Import-SIG mailing list