<br><br><div class="gmail_quote">On Wed, Nov 16, 2011 at 8:52 PM, Nick Coghlan <span dir="ltr">&lt;<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>&gt;</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? &quot;Oh, they told me something, but they might not mean it, so<br>
I&#39;ll choose to ignore the information they&#39;ve given me&quot; is the part<br>
that sounds like guessing to me.<br></blockquote><div> </div><div>Er, what? </div><div><br></div><div>They&#39;re not lying, they just made a mistake -- a mistake that could&#39;ve occurred at any point during a project&#39;s development, which would then only surface later.</div>
<div><br></div><div>As I said, I&#39;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 &quot;sure&quot; 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&#39;s wrong with their<br>
filesystem, that&#39;s the *opposite* of guessing.<br></blockquote><div><br></div><div>I&#39;m all in favor of warning or erroring out on aliasing __main__ or relative imports from __main__.  It&#39;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&#39;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&#39;t seem to make much sense to me.  But even if I granted that people with extra __init__.py&#39;s floating around should be punished for this (and I don&#39;t), this *still* wouldn&#39;t magically remove the existing ambiguity-of-intention in today&#39;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&#39;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&#39;ve been set up by yet another party.)</div>
<div><br></div><div>IOW, it&#39;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>