Module naming and declarations

Jason Orendorff jason.orendorff at
Tue May 7 16:39:20 PDT 2013

On Tue, May 7, 2013 at 1:49 PM, Kevin Smith <zenparsing at> wrote:

> Well, they're not URLs *except* when they are URLs - that's the problem.

Yeah, I can't entirely disagree. Permitting absolute URLs in imports seems
to be misleading, from what we've seen so far.

Most imports will be pretty boring, `import "underscore" as _;` and such.
If that's all we allowed, I don't think anyone would even think to call
them URLs.

And calling them "not URLs" is highly dubious in all cases.  Under the
> smoke and mirrors, they are effectively locators just like any URL.

Hmm. It's funny, you know, Python programs sometimes say

    import os

and I don't think anyone has ever claimed that the word "os" there is
really just a URL or really just a filename. Sure, there's an algorithm[1]
that maps that "os" to a filename—loading some code is after all the whole
point—but the mapping is configurable, and very often configured in some
non-default way. Same as in Java. Same as in Ruby.

Set aside absolute-url imports. Suppose we just dropped them. Would you
still think that module names are URLs? If so, do you think about other
languages in the same way?

So why does this proposal draw this particular response, "module names are
URLs"? I think it's the syntax. Python uses a dot in `import email.parser`;
the proposal uses a slash, which is more URL-like: `import "email/parser"
as emailparser;`. Python supports relative imports with a leading-dot
syntax, like `import .email.parser`, meaning
"<my_parent_package>.email.parser"; I think the proposal supports the same
thing using .., as in `import "../email/parser"`. All these elements, in
this context, seem to suggest "this is a URL" very strongly. Unfortunate,
as none of these examples are meant to be URLs at all.


[1] "How Import Works", at PyCon 2013
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list