<br><br><div class="gmail_quote">On Wed, Nov 16, 2011 at 8:52 PM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.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">Umm, if people screw up their filesystem layouts and *lie* to the</div>
interpreter about whether or not something is a package, how is that<br>
our fault? "Oh, they told me something, but they might not mean it, so<br>
I'll choose to ignore the information they've given me" is the part<br>
that sounds like guessing to me.<br></blockquote><div> </div><div>Er, what? </div><div><br></div><div>They're not lying, they just made a mistake -- a mistake that could've occurred at any point during a project's development, which would then only surface later.</div>
<div><br></div><div>As I said, I've seen projects where people had unnecessary __init__.py files floating around -- mainly because at some point they were trying any and everything to get package imports to work correctly, and somewhere along the line decided to just put __init__.py files everywhere just to be "sure" that things would work. (i.e. the sort of behavior PEP 402 is supposed to make unnecessary.)</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">If we error *immediately*, telling them what's wrong with their<br>
filesystem, that's the *opposite* of guessing.<br></blockquote><div><br></div><div>I'm all in favor of warning or erroring out on aliasing __main__ or relative imports from __main__. It's silently *succeeding* in doing something that might not have been intended on the basis of coincidental __init__.py placement that I have an issue with.</div>
<div><br></div><div>There exist projects that *intentionally* alias their modules as both a package and non-package (*cough* PIL *cough*), to name just *one* kind of *intentionally* weird sys.path setups, not counting unintentional ones like I mentioned. The simple fact is that you cannot unambiguously determine the intended meaning of a given script, and you certainly can't do it *before* the script executes (because it might already be doing some sys.path munging of its own.</div>
<div><br></div><div>Saying that people who made one kind of mistake or intentional change are lying, while a different set of people making mistakes deserve to have their mistake silently corrected doesn't seem to make much sense to me. But even if I granted that people with extra __init__.py's floating around should be punished for this (and I don't), this *still* wouldn't magically remove the existing ambiguity-of-intention in today's Python projects. Without some way for people to explicitly declare their intention (e.g. explicitly setting __qname__), you really have no way to definitely establish what the user's *intention* is. (Especially since the user who wrote the code and the user trying to use it might be different people.... and sys.path might've been set up by yet another party.)</div>
<div><br></div><div>IOW, it's ambiguous already, today, with or without 382, 402, or any other new PEP. (Heck, it was ambiguous before PEP 302 came around!)</div><div><br></div></div>