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

2010-07-12 Thread Nick Coghlan
On Tue, Jul 13, 2010 at 7:47 AM, Fred Drake wrote: > On Mon, Jul 12, 2010 at 5:42 PM, Michael Foord > wrote: >> I'm sure Brett will love this idea, but if it was impossible to reimport the >> script being executed as __main__ with a different name it would solve these >> problems. > > Indeed!  An

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

2010-07-12 Thread Michael Foord
On 12/07/2010 23:05, Nick Coghlan wrote: On Tue, Jul 13, 2010 at 7:47 AM, Fred Drake wrote: On Mon, Jul 12, 2010 at 5:42 PM, Michael Foord wrote: I'm sure Brett will love this idea, but if it was impossible to reimport the script being executed as __main__ with a different name it

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

2010-07-12 Thread Nick Coghlan
On Tue, Jul 13, 2010 at 8:06 AM, Michael Foord wrote: > An explicit error being raised instead would be just as good. Ah, refusing the temptation to guess. So the idea would be, when attempting to import __main__ under it's original name: 3.2 issue a DeprecationWarning 3.3 raise ImportError It

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

2010-07-12 Thread Michael Foord
On 12/07/2010 22:59, Antoine Pitrou wrote: On Mon, 12 Jul 2010 17:47:31 -0400 Fred Drake wrote: On Mon, Jul 12, 2010 at 5:42 PM, Michael Foord wrote: I'm sure Brett will love this idea, but if it was impossible to reimport the script being executed as __main__ with a different nam

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

2010-07-12 Thread Michael Foord
On 12/07/2010 23:23, Nick Coghlan wrote: On Tue, Jul 13, 2010 at 8:06 AM, Michael Foord wrote: An explicit error being raised instead would be just as good. Ah, refusing the temptation to guess. So the idea would be, when attempting to import __main__ under it's original name: 3.2

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

2010-07-12 Thread Steven D'Aprano
On Tue, 13 Jul 2010 08:05:24 am Nick Coghlan wrote: > On Tue, Jul 13, 2010 at 7:47 AM, Fred Drake wrote: > > On Mon, Jul 12, 2010 at 5:42 PM, Michael Foord > > > > wrote: > >> I'm sure Brett will love this idea, but if it was impossible to > >> reimport the script being executed as __main__ with

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

2010-07-13 Thread Michael Foord
On 13/07/2010 01:30, Steven D'Aprano wrote: On Tue, 13 Jul 2010 08:05:24 am Nick Coghlan wrote: On Tue, Jul 13, 2010 at 7:47 AM, Fred Drake wrote: On Mon, Jul 12, 2010 at 5:42 PM, Michael Foord wrote: I'm sure Brett will love this idea, but if it was impossible to reimpor

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

2010-07-13 Thread Nick Coghlan
> (Two different classes with the same name created - one from __main__ and > one from real_name.) Use cases for *genuinely* reimporting the same module > with different names (as different module objects rather than aliases) are > relatively rare, and the problem of modules *accidentally* reimport

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

2010-07-13 Thread Fred Drake
On Tue, Jul 13, 2010 at 9:00 AM, Nick Coghlan wrote: > Making sure both __main__ and the corresponding importable name refers > to the same module object seems reasonable. One detail that may not have been obvious when I described the persistent object problem; when class references are pickled,

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

2010-07-13 Thread Michael Foord
On 13/07/2010 14:00, Nick Coghlan wrote: (Two different classes with the same name created - one from __main__ and one from real_name.) Use cases for *genuinely* reimporting the same module with different names (as different module objects rather than aliases) are relatively rare, and the problem

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

2010-07-13 Thread Nick Coghlan
On Wed, Jul 14, 2010 at 2:25 AM, Michael Foord wrote: > Sure - there are trivial workarounds which is why I don't think there are > *many* genuine use cases for a module reimporting itself with a different > name. My concerns aren't about a module reimporting itself directly, they're about the ca

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

2010-07-13 Thread Fred Drake
On Tue, Jul 13, 2010 at 5:02 PM, Nick Coghlan 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. When an "application" is defined

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

2010-07-13 Thread Glyph Lefkowitz
On Jul 13, 2010, at 5:02 PM, Nick Coghlan wrote: > My concerns aren't about a module reimporting itself directly, they're > about the case where a utility module is invoked as __main__ but is > also imported normally somewhere else in a program (e.g. pdb is > invoked as a top-level debugger, but i

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

2010-07-13 Thread Nick Coghlan
On Wed, Jul 14, 2010 at 7:34 AM, Fred Drake wrote: > On Tue, Jul 13, 2010 at 5:02 PM, Nick Coghlan 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__ an