<div class="gmail_quote">On Wed, May 2, 2012 at 6:23 AM, 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">If it's the latter: yeah, it's a little strange. But find_module knows</div>
something that the caller needs to be told. It seemed easiest to add<br>
another possible return type. Any other suggestions?<br></blockquote><div><br></div><div>It seems quite elegant to me.</div><div><br></div><div>I do see one point of concern with the spec, though. At one point it says that finders must return a path without a trailing separator, but at another it says the package __file__ will contain a separator.</div>
<div><br></div><div>This strikes me as inconsistent, and also incompatible with non-filesystem-based finder implementations. The import machinery *must not* assume that import path strings are filenames, so it is wrong for the import machinery to add a path separator that the finder did not include.</div>
<div><br></div><div>IOW, I don't think the spec can assume or guarantee anything about the strings returned by finders: it MUST treat them as opaque strings. If this means that there can't be any meaningful __file__ for a namespace package, I think we will have to live with that.</div>
<div><br></div><div>The only alternative I see is to delegate the string manipulation back to the finders, or to change the return value from a string to a (file, path) tuple, wherein 'file' is the value to be used as __file__, and 'path' is the value to be used in __path__.</div>
<div><br></div></div>