<br><br><div class="gmail_quote">On Wed, May 2, 2012 at 1:24 PM, Eric V. Smith <span dir="ltr"><<a href="mailto:eric@trueblade.com" target="_blank">eric@trueblade.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 05/02/2012 01:06 PM, PJ Eby wrote:<br>
<br>
> I do see one point of concern with the spec, though. At one point it<br>
> says that finders must return a path without a trailing separator, but<br>
> at another it says the package __file__ will contain a separator.<br>
><br>
> This strikes me as inconsistent, and also incompatible with<br>
> non-filesystem-based finder implementations. The import machinery *must<br>
> not* assume that import path strings are filenames, so it is wrong for<br>
> the import machinery to add a path separator that the finder did not<br>
> include.<br>
><br>
> IOW, I don't think the spec can assume or guarantee anything about the<br>
> strings returned by finders: it MUST treat them as opaque strings. If<br>
> this means that there can't be any meaningful __file__ for a namespace<br>
> package, I think we will have to live with that.<br>
<br>
</div>I've come to the same conclusion myself. I actually had a draft of the<br>
PEP that removed the word "directory", at which point it becomes obvious<br>
that you're adding a path separator to something that might not be a<br>
path name.<br>
<div class="im"><br>
> The only alternative I see is to delegate the string manipulation back<br>
> to the finders, or to change the return value from a string to a (file,<br>
> path) tuple, wherein 'file' is the value to be used as __file__, and<br>
> 'path' is the value to be used in __path__.<br>
<br>
</div>I don't see the value of __file__ at all in the case of namespace<br>
packages. If it's just a hint that it's a namespace package, I think it<br>
would be better to set __file__ to None. That would noisily break some<br>
code that isn't likely to work anyway.<br></blockquote><div><br></div><div>Either None or a missing attribute is fine with me. (One advantage to the missing attribute is that it fails at the exact point where the inspecting code needs fixing, whereas the None will get passed on to some other code before the error manifests itsefl.)</div>
<div><br></div><div>By the way, I finished reading the rest of the PEP, and with regard to auto-updating paths, I want to mention that it wasn't me who originally brought up issues about auto-update, it was someone on Python-Dev, and the use cases were discussed there. Also, I would challenge the argument about it being a major block to implementation, since the implementation is straightforward (and TONS simpler than setuptools' approach to the problem).</div>
<div><br></div><div>More to the point, though, supporting auto-updates *later* is not really an option, since we'd be changing the rules on people, and invalidating whatever workarounds people come up with for manually updating the path. If namespace package __path__ objects start out as some other type than lists, then there's no change to trip anyone up later.</div>
<div><br></div><div>I guess my point is that if we're not going to do auto-updates from the start, it's kind of going to rule it out in the long term as well, so if that's the intention it should be explicitly addressed. I don't want to see it just get ruled out by default due to not being done now, and then not being able to be done later.</div>
<div><br></div><div>That's why my earlier question was about whether it had been discussed or not -- there was previous discussion on it in the 402 context, and it was left as an open issue pending BDFL comment on the basic idea of 402. Since then, the basic idea of treating init-less directories as namespace packages has been blessed, so now it's time to get the auto-updates yea-or-nay question ruled on as well.</div>
<div><br></div><div>The implementation is pretty trivial; see PEP 402 version of it here:</div><div><br></div><div> <a href="http://mail.python.org/pipermail/import-sig/2012-April/000473.html">http://mail.python.org/pipermail/import-sig/2012-April/000473.html</a>
</div><div><br></div><div>...and the PEP 420 version is even simpler, since instead of looking for a 'get_subpath()' method on the finders, it should just call find_module() and check for a string return.</div></div>