<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.</blockquote><div><br></div><div>Problem is that None for __file__ would be a unique use here. Frozen modules, for instance, typically say "<frozen>" for __file__. Now part of the reason (I suspect) this is done is that this was the only way to tell how the module was created, but with __loader__ now on all modules this is redundant. So perhaps this fake value for __file__ is just outdated and not worth perpetuating?</div>
<div><br></div><div>I vote for using __file__ as None as suggested and having people infer how the module was created from __loader__. </div></div>