github at esdiscuss.org (2013-07-12T02:27:22.456Z)
On Tue, May 7, 2013 at 1:49 PM, Kevin Smith <zenparsing at gmail.com> 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](http://youtu.be/AqnxyRuenAg)
On Tue, May 7, 2013 at 1:49 PM, Kevin Smith <zenparsing at gmail.com> 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. -j [1] "How Import Works", at PyCon 2013 http://youtu.be/AqnxyRuenAg -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130507/a0b6e0bb/attachment.html>