[Python-Dev] avoiding accidental shadowing of top-level libraries by the main module

[Nick Coghlan]

On Wed, Jul 14, 2010 at 7:34 AM, Fred Drake <fdrake at acm.org> wrote:
> On Tue, Jul 13, 2010 at 5:02 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> Fred's point about the practice of changing __name__ in the main
>> module corrupting generated pickles is one I hadn't thought of before
>> though.
>
> Not sure about changing __name__ anywhere... I don't do that.

The interpreter does though (when it sets it to "__main__" instead of
what it would have been if the module had been imported rather than
executed).

That fact is convincing me that we should leave this alone for now. A
module imported as __main__ and a module imported under it's real name
are *different*, and this is reflected in pickles they generate and
anything else that remembers the values of __name__. Obscuring that by
treating them as equivalent in some contexts (such as name shadowing)
while they remain different in other significant ways is unlikely to
help overall.

I must say, this whole discussion is actually making me far more
sympathetic to the ideas behind PEP 299 (which proposed __main__
functions as a replacement for __name__ == "__main__" blocks). Brett's
rejected PEP 3122 and my own accepted PEP 366 were both a direct
result of the interpreter lying about the real value of __name__. I
don't have a particular good way forward though, and the one thing I
can say about the status quo is that at least everyone is accustomed
to having to work around it.

And back to the topic of inadvertent shadowing when teaching new
users: PEP 3147 should actually help in that regard, as the
interpreter will now ignore any implicitly created .pyc files if the
corresponding .py file has been removed. Only explicitly created .pyc
files that live where the source file would have been can completely
substitute for a missing source file now.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia