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
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
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
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
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
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,
> (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
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
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
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
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
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
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
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
14 matches
Mail list logo
