On Sun, Aug 1, 2010 at 1:36 AM, Michael Foord wrote:
> On 31/07/2010 16:30, Nick Coghlan wrote:
>> With my change, that code would work just fine. "from myproject.gizmo
>> import main" and "from __main__ import main" would just return the
>> same object, whereas currently they return something dif
On Sun, Aug 1, 2010 at 1:23 AM, Alexander Belopolsky
wrote:
> On Sat, Jul 31, 2010 at 11:07 AM, Nick Coghlan wrote:
> ..
>> That said, I really don't think catching such a rare error is worth
>> *any* runtime overhead. Just making "__main__" and the real module
>> name refer to the same object in
On 31/07/2010 16:30, Nick Coghlan wrote:
On Sun, Aug 1, 2010 at 1:14 AM, Michael Foord wrote:
Some people workaround the potential for bugs caused by __main__ reimporting
itself by doing it *deliberately*. Glyf even recommends it as good practise.
;-)
http://glyf.livejournal.com/60326.html
On Sun, Aug 1, 2010 at 1:14 AM, Michael Foord wrote:
> Some people workaround the potential for bugs caused by __main__ reimporting
> itself by doing it *deliberately*. Glyf even recommends it as good practise.
> ;-)
>
> http://glyf.livejournal.com/60326.html
>
> So - the fix you suggest would *br
On Sat, Jul 31, 2010 at 11:07 AM, Nick Coghlan wrote:
..
> That said, I really don't think catching such a rare error is worth
> *any* runtime overhead. Just making "__main__" and the real module
> name refer to the same object in sys.modules is a different matter,
> but I'm not confident enough t
On 31/07/2010 16:07, Nick Coghlan wrote:
On Sat, Jul 31, 2010 at 3:57 PM, Daniel Waterworth
wrote:
@Nick: I suppose the simplest way to detect re-importation in the
general case, is to store a set of hashes of files that have been
imported. When a user tries to import a file where it's has
On Sat, Jul 31, 2010 at 3:57 PM, Daniel Waterworth
wrote:
> @Nick: I suppose the simplest way to detect re-importation in the
> general case, is to store a set of hashes of files that have been
> imported. When a user tries to import a file where it's hash is
> already in the set, a warning is gen
On 31 July 2010 02:21, Alexander Belopolsky
wrote:
> On Fri, Jul 30, 2010 at 2:46 PM, Daniel Waterworth
> wrote:
> ..
>> Having thought it through thoroughly, my preference is for a warning.
>>
>> I don't think it's a good practise to import the __main__ module by
>> filename, as renaming the fil
On Fri, Jul 30, 2010 at 2:46 PM, Daniel Waterworth
wrote:
..
> Having thought it through thoroughly, my preference is for a warning.
>
> I don't think it's a good practise to import the __main__ module by
> filename, as renaming the file will break the code. I got stung after,
> having dropped int
On Sat, Jul 31, 2010 at 4:46 AM, Daniel Waterworth
wrote:
> Having thought it through thoroughly, my preference is for a warning.
That's actually harder than it sounds.
Inserting "__main__" into sys.modules under its normal name as well as
"__main__" is actually pretty easy (for both direct exec
At 11:50 PM 7/30/2010 +0400, Oleg Broytman wrote:
On Fri, Jul 30, 2010 at 07:46:44PM +0100, Daniel Waterworth wrote:
> can anyone think of a case where someone has
> been annoyed that, having imported that same module twice via
> symlinks, they have had problems relating to modules being independ
On Fri, Jul 30, 2010 at 07:46:44PM +0100, Daniel Waterworth wrote:
> can anyone think of a case where someone has
> been annoyed that, having imported that same module twice via
> symlinks, they have had problems relating to modules being independent
> instances?
I've had problems with two inst
On 30 July 2010 18:32, Michael Foord wrote:
> On 30/07/2010 17:59, Oleg Broytman wrote:
>>
>> On Fri, Jul 30, 2010 at 07:26:26AM +0100, Daniel Waterworth wrote:
>>
>>>
>>> @Oleg: ...
>>> This is purely CPython bug-fixing/the discussion of
>>> implementation choices.
>>>
>>
>> I am not sure it's
On 30/07/2010 17:59, Oleg Broytman wrote:
On Fri, Jul 30, 2010 at 07:26:26AM +0100, Daniel Waterworth wrote:
@Oleg: ...
This is purely CPython bug-fixing/the discussion of
implementation choices.
I am not sure it's a bug.
It isn't a bug but it's a very common *cause* of bugs, ev
On Fri, Jul 30, 2010 at 07:26:26AM +0100, Daniel Waterworth wrote:
> @Oleg: ...
> This is purely CPython bug-fixing/the discussion of
> implementation choices.
I am not sure it's a bug. By manipulating sys.path (or symlinks in the
FS) one can import the same file as different modules as many ti
On 29 July 2010 07:32, Daniel Waterworth wrote:
> Hi,
>
> I'm not sure if this is a bug or not, I certainly didn't expect it. If
> you create a file called test.py with the following contents,
>
> class Test:
> pass
>
> def test_1():
> import test
> print Test == test.Test
>
> if __name__
On 29/07/2010 07:32, Daniel Waterworth wrote:
Hi,
I'm not sure if this is a bug or not, I certainly didn't expect it. If
you create a file called test.py with the following contents,
The issue is that when your code is executed as a script it is run as
the __main__ module and not as the t
On Thu, Jul 29, 2010 at 4:32 PM, Daniel Waterworth
wrote:
> Hi,
>
> I'm not sure if this is a bug or not, I certainly didn't expect it. If
> you create a file called test.py with the following contents,
>
> class Test:
> pass
>
> def test_1():
> import test
> print Test == test.Test
>
> i
Hello.
We are sorry but we cannot help you. This mailing list is to work on
developing Python (adding new features to Python itself and fixing bugs);
if you're having problems learning, understanding or using Python, please
find another forum. Probably python-list/comp.lang.python mailing list/
Hi,
I'm not sure if this is a bug or not, I certainly didn't expect it. If
you create a file called test.py with the following contents,
class Test:
pass
def test_1():
import test
print Test == test.Test
if __name__ == '__main__':
test_1()
and then run it ($ python test.py), it
20 matches
Mail list logo
