On 08Aug2012 14:14, Ben Finney wrote:
| Cameron Simpson writes:
| > All of you are saying "two names for the same module", and variations
| > thereof. And that is why the doco confuses.
| >
| > I would expect less confusion if the above example were described as
| > _two_ modules, with the same s
In article <87hasehvfu@benfinney.id.au>,
Ben Finney wrote:
> Cameron Simpson writes:
>
> > All of you are saying "two names for the same module", and variations
> > thereof. And that is why the doco confuses.
> >
> > I would expect less confusion if the above example were described as
> >
Roy Smith wrote:
So, it appears that you *can* import a module twice, if you refer to it by
different names! This is surprising. It means that having non-idempotent code
which is executed at import time is a Bad Thing.
Not exactly, it means that one module is different from another if its
On 2012-08-08 06:14, Ben Finney wrote:
Cameron Simpson writes:
All of you are saying "two names for the same module", and variations
thereof. And that is why the doco confuses.
I would expect less confusion if the above example were described as
_two_ modules, with the same source code.
That
Cameron Simpson writes:
> All of you are saying "two names for the same module", and variations
> thereof. And that is why the doco confuses.
>
> I would expect less confusion if the above example were described as
> _two_ modules, with the same source code.
That's not true though, is it? It's t
In article ,
Cameron Simpson wrote:
> This, I think, is a core issue in this misunderstanding. (I got bitten
> by this too, maybe a year ago. My error, and I'm glad to have improved
> my understanding.)
>
> All of you are saying "two names for the same module", and variations
> thereof. And tha
On 07Aug2012 13:52, Steven D'Aprano
wrote:
| On Tue, 07 Aug 2012 09:18:26 -0400, Roy Smith wrote:
| > I thought modules could not get imported twice. The first time they get
| > imported, they're cached, and the second import just gets you a
| > reference to the original. Playing around, howeve
On Tue, 07 Aug 2012 08:25:43 -0700, Roy Smith wrote:
> On Tuesday, August 7, 2012 9:52:59 AM UTC-4, Steven D'Aprano wrote:
>
>> In general, you should avoid non-idempotent code. You should doubly
>> avoid it during imports, and triply avoid it on days ending with Y.
You seem to have accidentally
On 07/08/2012 14:18, Roy Smith wrote:
I've been tracking down some weird import problems we've been having with
django. Our settings.py file is getting imported twice. It has some
non-idempotent code in it, and we blow up on the second import.
I thought modules could not get imported twice. T
On 8/7/2012 11:32 AM, Roy Smith wrote:
On Tuesday, August 7, 2012 9:55:16 AM UTC-4, Ben Finney wrote:
The tutorial is misleading on this. It it says plainly:
A module can contain executable statements as well as function
definitions. […] They are executed only the *first* time the
module is im
On 8/7/2012 9:28 AM, Ramchandra Apte wrote:
I don't think the modules are actually imported twice.
This is incorrect as Roy's original unposted example showed.
Modify one of the two copies and it will be more obvious.
PS. I agree with Mark about top posting. I often just glance as such
postin
On Aug 7, 2012 8:41 AM, "Roy Smith" wrote:
>
> On Tuesday, August 7, 2012 9:55:16 AM UTC-4, Ben Finney wrote:
>
> > The tutorial is misleading on this. It it says plainly:
> >
> > A module can contain executable statements as well as function
> > definitions. […] They are executed only th
Roy Smith writes:
>> In general, you should avoid non-idempotent code.
> I don't understand your aversion to non-idempotent code as a general
> rule. Most code is non-idempotent. Surely you're not saying we
> should never write:
foo += 1
> or
my_list.pop()
> ???
I don't think "in gen
On Tuesday, August 7, 2012 9:55:16 AM UTC-4, Ben Finney wrote:
> The tutorial is misleading on this. It it says plainly:
>
> A module can contain executable statements as well as function
> definitions. […] They are executed only the *first* time the module
> is imported somewhere.
>
On Tuesday, August 7, 2012 9:52:59 AM UTC-4, Steven D'Aprano wrote:
> In general, you should avoid non-idempotent code. You should
> doubly avoid it during imports, and triply avoid it on days ending with Y.
I don't understand your aversion to non-idempotent code as a general rule.
Most code i
On 2012-08-07 15:55, Ben Finney wrote:
Roy Smith writes:
So, it appears that you *can* import a module twice, if you refer to
it by different names! This is surprising.
The tutorial is misleading on this. It it says plainly:
A module can contain executable statements as well as function
On 07/08/2012 14:28, Ramchandra Apte wrote:
I don't think the modules are actually imported twice. The entry is just
doubled;that's all
Please don't top post, this is the third time of asking.
--
Cheers.
Mark Lawrence.
--
http://mail.python.org/mailman/listinfo/python-list
Roy Smith writes:
> So, it appears that you *can* import a module twice, if you refer to
> it by different names! This is surprising.
The tutorial is misleading on this. It it says plainly:
A module can contain executable statements as well as function
definitions. […] They are executed
On Tue, 07 Aug 2012 09:18:26 -0400, Roy Smith wrote:
> I thought modules could not get imported twice. The first time they get
> imported, they're cached, and the second import just gets you a
> reference to the original. Playing around, however, I see that it's
> possible to import a module twi
I don't think the modules are actually imported twice. The entry is just
doubled;that's all
On 7 August 2012 18:48, Roy Smith wrote:
> I've been tracking down some weird import problems we've been having with
> django. Our settings.py file is getting imported twice. It has some
> non-idempoten
20 matches
Mail list logo
