[ python-Bugs-1383644 ] MacOS.WMAvailable() doesn't launch Python.app properly
Bugs item #1383644, was opened at 2005-12-17 17:12 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1383644&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Platform-specific >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: has (hhas) Assigned to: Jack Jansen (jackjansen) Summary: MacOS.WMAvailable() doesn't launch Python.app properly Initial Comment: Running the following on Apple-installed Python 2.3.5 on OS 10.4.3: ~ has$ pythonw Python 2.3.5 (#1, Mar 20 2005, 20:38:20) [GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import MacOS >>> MacOS.WMAvailable() True a Python.app process starts to launch as expected; however its icon remains bouncing indefinitely in the Dock. Additional prodding, e.g.: >>> import Carbon.Evt >>> Carbon.Evt.WaitNextEvent(0,0) (0, (0, 0, 1141622, (751, 225), 128)) causes it to finish launching as expected (Dock icon stops bouncing, small black triangle appears next to it). Third-party has confirmed this problem. Might be a problem with WMAvailable(), might be a problem in Python.app. Don't know enough Carbon to determine this myself. -- >Comment By: Jack Jansen (jackjansen) Date: 2005-12-20 12:10 Message: Logged In: YES user_id=45365 This is not a bug: this is expected behaviour:-) Note that nothing is "launched" by WMavailable() or WaitNextEvent(): the only thing these calls do is signal the existence of pythonw (or actually Python.app) to the window manager. Before WMAvailable() is called the window manager knows nothing about Python.app, so nothing is shown in the dock. WMavailable() causes the very first WM call, which (among other things) make the dock icon appear and start bouncing. The "end of bouncing" happens when the WM notices the app has gone into its event loop, which is indeed signalled by calling WNE() or something similar. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1383644&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1376775 ] Memory leak in the email package
Bugs item #1376775, was opened at 2005-12-09 02:03
Message generated for change (Settings changed) made by effbot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: ken668 (ken668)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Memory leak in the email package
Initial Comment:
memory leak in email.message_from_string. This is what
I did to create a leak.
You used the attached file, memleak.eml.
f = open("memleak.eml")
buffer = f.read()
f.close()
# now buffer has the email string
msg = email.message_from_string(buffer)
msg = None # this should free the memory but it doesn't
# The memory that is used in msg is not completely free
--
>Comment By: Fredrik Lundh (effbot)
Date: 2005-12-20 17:44
Message:
Logged In: YES
user_id=38376
This is not a leak (a leak means that the process will
grow if you *repeat* the operation, not that things are
unexpectedly left in the object memory).
And it's not a bug, either; the "copy" of the message
that's returned by get_objects() is the contents of the
buffer variable in the test program.
--
Comment By: ken668 (ken668)
Date: 2005-12-15 07:44
Message:
Logged In: YES
user_id=1400763
Yes, it is a bug. My mistake was when I gave the details, I
should have mentioned gc.get_objects(), not gc.garbage.
gc.get_objects() showed the leaks not gc.garbage.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-15 06:56
Message:
Logged In: YES
user_id=33168
Do you still believe there is a problem or can this report
be closed?
--
Comment By: ken668 (ken668)
Date: 2005-12-12 17:00
Message:
Logged In: YES
user_id=1400763
My mistake. I had also called gc.get_objects() too. It was
gc.get_objects() that outputed the content of the email
message. It was not gc.garbage. Sorry about that.
--
Comment By: ken668 (ken668)
Date: 2005-12-12 16:59
Message:
Logged In: YES
user_id=1400763
My mistake. I had also called gc.get_objects() too. It was
gc.get_objects() that outputed the content of the email
message. It was not gc.garbage. Sorry about that.
--
Comment By: ken668 (ken668)
Date: 2005-12-12 16:53
Message:
Logged In: YES
user_id=1400763
I added these three lines after the line "msg=None"
import gc
print "gc.collect()\n\n", gc.collect()
print "gc.garbage\n\n", gc.garbage
If you pipe the output of gc.garbage to a file, you will see
the email message you just sent are still be in the memory.
Everytime I call email.message_from_string, a copy of the
message will be kept in the memory even after I set the
returned value to None.
I tried the same thing with email package email-2.5.tar.gz,
that memory was freed right after I set the variable "msg"
to None.
Thanks
Ken
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-11 21:13
Message:
Logged In: YES
user_id=33168
What causes you to believe this is a memory leak? I ran
this under valgrind and it doesn't report any leaks.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1376775 ] Memory leak in the email package
Bugs item #1376775, was opened at 2005-12-08 17:03
Message generated for change (Comment added) made by ken668
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: ken668 (ken668)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Memory leak in the email package
Initial Comment:
memory leak in email.message_from_string. This is what
I did to create a leak.
You used the attached file, memleak.eml.
f = open("memleak.eml")
buffer = f.read()
f.close()
# now buffer has the email string
msg = email.message_from_string(buffer)
msg = None # this should free the memory but it doesn't
# The memory that is used in msg is not completely free
--
>Comment By: ken668 (ken668)
Date: 2005-12-20 10:37
Message:
Logged In: YES
user_id=1400763
May be you did not look at my test program more closely.
Please look at the statement msg=None. The should removed
all references of the object. The memory will definely grow
if you repeat the operation. Why don't you run the
email.message_from_string in a loop and see whether the
memory grows. Thanks.
--
Comment By: Fredrik Lundh (effbot)
Date: 2005-12-20 08:44
Message:
Logged In: YES
user_id=38376
This is not a leak (a leak means that the process will
grow if you *repeat* the operation, not that things are
unexpectedly left in the object memory).
And it's not a bug, either; the "copy" of the message
that's returned by get_objects() is the contents of the
buffer variable in the test program.
--
Comment By: ken668 (ken668)
Date: 2005-12-14 22:44
Message:
Logged In: YES
user_id=1400763
Yes, it is a bug. My mistake was when I gave the details, I
should have mentioned gc.get_objects(), not gc.garbage.
gc.get_objects() showed the leaks not gc.garbage.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-14 21:56
Message:
Logged In: YES
user_id=33168
Do you still believe there is a problem or can this report
be closed?
--
Comment By: ken668 (ken668)
Date: 2005-12-12 08:00
Message:
Logged In: YES
user_id=1400763
My mistake. I had also called gc.get_objects() too. It was
gc.get_objects() that outputed the content of the email
message. It was not gc.garbage. Sorry about that.
--
Comment By: ken668 (ken668)
Date: 2005-12-12 07:59
Message:
Logged In: YES
user_id=1400763
My mistake. I had also called gc.get_objects() too. It was
gc.get_objects() that outputed the content of the email
message. It was not gc.garbage. Sorry about that.
--
Comment By: ken668 (ken668)
Date: 2005-12-12 07:53
Message:
Logged In: YES
user_id=1400763
I added these three lines after the line "msg=None"
import gc
print "gc.collect()\n\n", gc.collect()
print "gc.garbage\n\n", gc.garbage
If you pipe the output of gc.garbage to a file, you will see
the email message you just sent are still be in the memory.
Everytime I call email.message_from_string, a copy of the
message will be kept in the memory even after I set the
returned value to None.
I tried the same thing with email package email-2.5.tar.gz,
that memory was freed right after I set the variable "msg"
to None.
Thanks
Ken
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-11 12:13
Message:
Logged In: YES
user_id=33168
What causes you to believe this is a memory leak? I ran
this under valgrind and it doesn't report any leaks.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1376775 ] Memory leak in the email package
Bugs item #1376775, was opened at 2005-12-09 02:03
Message generated for change (Comment added) made by effbot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: ken668 (ken668)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Memory leak in the email package
Initial Comment:
memory leak in email.message_from_string. This is what
I did to create a leak.
You used the attached file, memleak.eml.
f = open("memleak.eml")
buffer = f.read()
f.close()
# now buffer has the email string
msg = email.message_from_string(buffer)
msg = None # this should free the memory but it doesn't
# The memory that is used in msg is not completely free
--
>Comment By: Fredrik Lundh (effbot)
Date: 2005-12-20 20:03
Message:
Logged In: YES
user_id=38376
Nope.
If you do msg=None, you'll release a reference to the
message object, and all direct, non-cyclic members.
Any cyclic references held by the message object (or
created by the email parser) will be removed at a later
time, by the garbage collector.
And even if you add an explicit gc.collect() call to
your program, that won't remove the contents of the
*buffer* variable.
(If you run the program in a loop *without* an explicit
gc.collect() call, the process will appear to grow for
a while, since you're creating objects faster than the
GC can remove them. Add gc.collect() to the loop, and
the memory use will be rock solid.)
--
Comment By: ken668 (ken668)
Date: 2005-12-20 19:37
Message:
Logged In: YES
user_id=1400763
May be you did not look at my test program more closely.
Please look at the statement msg=None. The should removed
all references of the object. The memory will definely grow
if you repeat the operation. Why don't you run the
email.message_from_string in a loop and see whether the
memory grows. Thanks.
--
Comment By: Fredrik Lundh (effbot)
Date: 2005-12-20 17:44
Message:
Logged In: YES
user_id=38376
This is not a leak (a leak means that the process will
grow if you *repeat* the operation, not that things are
unexpectedly left in the object memory).
And it's not a bug, either; the "copy" of the message
that's returned by get_objects() is the contents of the
buffer variable in the test program.
--
Comment By: ken668 (ken668)
Date: 2005-12-15 07:44
Message:
Logged In: YES
user_id=1400763
Yes, it is a bug. My mistake was when I gave the details, I
should have mentioned gc.get_objects(), not gc.garbage.
gc.get_objects() showed the leaks not gc.garbage.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-15 06:56
Message:
Logged In: YES
user_id=33168
Do you still believe there is a problem or can this report
be closed?
--
Comment By: ken668 (ken668)
Date: 2005-12-12 17:00
Message:
Logged In: YES
user_id=1400763
My mistake. I had also called gc.get_objects() too. It was
gc.get_objects() that outputed the content of the email
message. It was not gc.garbage. Sorry about that.
--
Comment By: ken668 (ken668)
Date: 2005-12-12 16:59
Message:
Logged In: YES
user_id=1400763
My mistake. I had also called gc.get_objects() too. It was
gc.get_objects() that outputed the content of the email
message. It was not gc.garbage. Sorry about that.
--
Comment By: ken668 (ken668)
Date: 2005-12-12 16:53
Message:
Logged In: YES
user_id=1400763
I added these three lines after the line "msg=None"
import gc
print "gc.collect()\n\n", gc.collect()
print "gc.garbage\n\n", gc.garbage
If you pipe the output of gc.garbage to a file, you will see
the email message you just sent are still be in the memory.
Everytime I call email.message_from_string, a copy of the
message will be kept in the memory even after I set the
returned value to None.
I tried the same thing with email package email-2.5.tar.gz,
that memory was freed right after I set the variable "msg"
to None.
Thanks
Ken
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-11 21:13
Message:
Logged In: YES
user_id=33168
What causes you to believe this is a memory leak? I ran
this under valgrind and it doesn't report any leaks.
-
[ python-Bugs-1376775 ] Memory leak in the email package
Bugs item #1376775, was opened at 2005-12-08 17:03
Message generated for change (Comment added) made by ken668
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: ken668 (ken668)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Memory leak in the email package
Initial Comment:
memory leak in email.message_from_string. This is what
I did to create a leak.
You used the attached file, memleak.eml.
f = open("memleak.eml")
buffer = f.read()
f.close()
# now buffer has the email string
msg = email.message_from_string(buffer)
msg = None # this should free the memory but it doesn't
# The memory that is used in msg is not completely free
--
>Comment By: ken668 (ken668)
Date: 2005-12-20 14:11
Message:
Logged In: YES
user_id=1400763
I assume the new email package has cyclic references in it.
My program has garabage collection disabled because of
performance issues. That means the email package will cause
memory leak in my program. I will use the old package
instead. Thanks for the help.
--
Comment By: Fredrik Lundh (effbot)
Date: 2005-12-20 11:03
Message:
Logged In: YES
user_id=38376
Nope.
If you do msg=None, you'll release a reference to the
message object, and all direct, non-cyclic members.
Any cyclic references held by the message object (or
created by the email parser) will be removed at a later
time, by the garbage collector.
And even if you add an explicit gc.collect() call to
your program, that won't remove the contents of the
*buffer* variable.
(If you run the program in a loop *without* an explicit
gc.collect() call, the process will appear to grow for
a while, since you're creating objects faster than the
GC can remove them. Add gc.collect() to the loop, and
the memory use will be rock solid.)
--
Comment By: ken668 (ken668)
Date: 2005-12-20 10:37
Message:
Logged In: YES
user_id=1400763
May be you did not look at my test program more closely.
Please look at the statement msg=None. The should removed
all references of the object. The memory will definely grow
if you repeat the operation. Why don't you run the
email.message_from_string in a loop and see whether the
memory grows. Thanks.
--
Comment By: Fredrik Lundh (effbot)
Date: 2005-12-20 08:44
Message:
Logged In: YES
user_id=38376
This is not a leak (a leak means that the process will
grow if you *repeat* the operation, not that things are
unexpectedly left in the object memory).
And it's not a bug, either; the "copy" of the message
that's returned by get_objects() is the contents of the
buffer variable in the test program.
--
Comment By: ken668 (ken668)
Date: 2005-12-14 22:44
Message:
Logged In: YES
user_id=1400763
Yes, it is a bug. My mistake was when I gave the details, I
should have mentioned gc.get_objects(), not gc.garbage.
gc.get_objects() showed the leaks not gc.garbage.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-14 21:56
Message:
Logged In: YES
user_id=33168
Do you still believe there is a problem or can this report
be closed?
--
Comment By: ken668 (ken668)
Date: 2005-12-12 08:00
Message:
Logged In: YES
user_id=1400763
My mistake. I had also called gc.get_objects() too. It was
gc.get_objects() that outputed the content of the email
message. It was not gc.garbage. Sorry about that.
--
Comment By: ken668 (ken668)
Date: 2005-12-12 07:59
Message:
Logged In: YES
user_id=1400763
My mistake. I had also called gc.get_objects() too. It was
gc.get_objects() that outputed the content of the email
message. It was not gc.garbage. Sorry about that.
--
Comment By: ken668 (ken668)
Date: 2005-12-12 07:53
Message:
Logged In: YES
user_id=1400763
I added these three lines after the line "msg=None"
import gc
print "gc.collect()\n\n", gc.collect()
print "gc.garbage\n\n", gc.garbage
If you pipe the output of gc.garbage to a file, you will see
the email message you just sent are still be in the memory.
Everytime I call email.message_from_string, a copy of the
message will be kept in the memory even after I set the
returned value to None.
I tried the same thing with email packag
[ python-Bugs-1386675 ] _winreg specifies EnvironmentError instead of WindowsError
Bugs item #1386675, was opened at 2005-12-21 14:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1386675&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Nobody/Anonymous (nobody) Summary: _winreg specifies EnvironmentError instead of WindowsError Initial Comment: The _winreg documentation says that EnvironmentError will be raised (throughout the docs, for various reasons), when, in every case, WindowsError is actually raised. A simple replace of WindowsError for EnvironmentError would fix this. (Let me know if you really need a patch). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1386675&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1311784 ] python.exe 2.4.2 compiled with VS2005 crashes
Bugs item #1311784, was opened at 2005-10-03 05:18 Message generated for change (Comment added) made by khepri You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311784&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Closed Resolution: Duplicate Priority: 5 Submitted By: Peter Klotz (pete_icoserve) Assigned to: Nobody/Anonymous (nobody) Summary: python.exe 2.4.2 compiled with VS2005 crashes Initial Comment: The C runtime library shipped with Visual Studio 2005 performs strict checking of parameters. In function initsignal() in file Modules\signalmodule.c, an iteration over all signals from 1 to NSIG is performed. The function PyOS_getsig() is called with each of these integer values. PyOS_getsig() then calls signal() with the given value which leads to the crash. According to signal.h from VS2005 only these signals are allowed: #define SIGINT 2 #define SIGILL 4 #define SIGABRT_COMPAT 6 #define SIGFPE 8 #define SIGSEGV 11 #define SIGTERM 15 #define SIGBREAK21 #define SIGABRT 22 A solution would be to restrict the loop in initsignal() to the above values under Windows. -- Comment By: Kirjah Salys (khepri) Date: 2005-12-20 21:28 Message: Logged In: YES user_id=488858 VS2005 is out, and this bug still occurs in the release version (of both Python and VS2005). Is there any workaround for this? I can't see any being posted, and I replaced my system-wide compiler. It wouldn't exactly be feasible to accept the basic binary distribution or 'downgrade' my compiler in any event (Python has library binary compatibility problems in a wide variety of cases with external programs/libraries). Is Python's official stance to still pretend that VS2005 doesn't exist? And while it's probable that this violates standard (what compiler/library doesn't nowadays? *bleh*), and the 'deprecation warnings' get on nerves, this causes Python to crash "for no good reason" when compiled with it. -- Comment By: Martin v. Löwis (loewis) Date: 2005-10-12 00:56 Message: Logged In: YES user_id=21627 Thanks for pointing out the earlier report, closing this one as a duplicate. Re: the platform SDK includes the same CRT: I somewhat doubt that statement. In my copy of the SDK, I have a msvcrt.dll version 6.10.2207.0, and the CRT sources don't have assertions in them. I can't ultimately test this, though, as I don't have the hardware. Re: it's an assertion. So does everybody agree that this is not conforming to ISO C? It should be worked-around in Python, sure, but preferably only after the release of the compiler, and preferably only after researching alternative solutions in the CRT sources of VS2005. -- Comment By: Peter Klotz (pete_icoserve) Date: 2005-10-12 00:01 Message: Logged In: YES user_id=299547 Re: AMD64 compilers are available as part of the current platform SDK as available to MSDN subscribers (not through the free SDK download), and also reportedly available as part of the DDK. It is true that the current platform SDK supports AMD64 but the included compiler has version number 14.00 and comes with the same C runtime that is shipped with VS2005. I should have stated 'there is no AMD64 support prior to cl 14.00' rather than 'there is no AMD64 support prior to VS2005'. Nevertheless if you have to compile for AMD64 under Windows you have to use cl 14.00 and you cannot avoid the C runtime library showing the new signal behavior. -- Comment By: Adal Chiriliuc (adalx) Date: 2005-10-11 17:17 Message: Logged In: YES user_id=1067739 This has been reported before. Maybe these two bugs should me merged somehow: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167262&group_id=5470 The older bug report states that it's an assertion error, not a crash. That's consistent with the recent security clean-up of the CRT in VS 2005. I don't think that MS will fix this, since they are the ones which added the extra assertions. I've looked through the source code of the .NET 2003 version and it works as in ANSI-C (SIG_ERR is returned for unknown signals). -- Comment By: Martin v. Löwis (loewis) Date: 2005-10-11 16:36 Message: Logged In: YES user_id=21627 Re: this should be fixed: It certainly should (but doing so is less important than fixing problems which affect the actual distribution). Re: Conformance with ISO C. "implementation-defined" is not "undefined". Imp
[ python-Bugs-1311784 ] python.exe 2.4.2 compiled with VS2005 crashes
Bugs item #1311784, was opened at 2005-10-03 05:18 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311784&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Closed Resolution: Duplicate Priority: 5 Submitted By: Peter Klotz (pete_icoserve) Assigned to: Nobody/Anonymous (nobody) Summary: python.exe 2.4.2 compiled with VS2005 crashes Initial Comment: The C runtime library shipped with Visual Studio 2005 performs strict checking of parameters. In function initsignal() in file Modules\signalmodule.c, an iteration over all signals from 1 to NSIG is performed. The function PyOS_getsig() is called with each of these integer values. PyOS_getsig() then calls signal() with the given value which leads to the crash. According to signal.h from VS2005 only these signals are allowed: #define SIGINT 2 #define SIGILL 4 #define SIGABRT_COMPAT 6 #define SIGFPE 8 #define SIGSEGV 11 #define SIGTERM 15 #define SIGBREAK21 #define SIGABRT 22 A solution would be to restrict the loop in initsignal() to the above values under Windows. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-20 21:43 Message: Logged In: YES user_id=33168 If you track down the references you will find the change has been made to the CM repository in revision 41554. See patch: http://sourceforge.net/tracker/index.php?func=detail&aid=1350409&group_id=5470&atid=305470 The work around is to download the source and build python yourself, ensuring the patch is applied. How do you propose we backpatch already released versions? -- Comment By: Kirjah Salys (khepri) Date: 2005-12-20 21:28 Message: Logged In: YES user_id=488858 VS2005 is out, and this bug still occurs in the release version (of both Python and VS2005). Is there any workaround for this? I can't see any being posted, and I replaced my system-wide compiler. It wouldn't exactly be feasible to accept the basic binary distribution or 'downgrade' my compiler in any event (Python has library binary compatibility problems in a wide variety of cases with external programs/libraries). Is Python's official stance to still pretend that VS2005 doesn't exist? And while it's probable that this violates standard (what compiler/library doesn't nowadays? *bleh*), and the 'deprecation warnings' get on nerves, this causes Python to crash "for no good reason" when compiled with it. -- Comment By: Martin v. Löwis (loewis) Date: 2005-10-12 00:56 Message: Logged In: YES user_id=21627 Thanks for pointing out the earlier report, closing this one as a duplicate. Re: the platform SDK includes the same CRT: I somewhat doubt that statement. In my copy of the SDK, I have a msvcrt.dll version 6.10.2207.0, and the CRT sources don't have assertions in them. I can't ultimately test this, though, as I don't have the hardware. Re: it's an assertion. So does everybody agree that this is not conforming to ISO C? It should be worked-around in Python, sure, but preferably only after the release of the compiler, and preferably only after researching alternative solutions in the CRT sources of VS2005. -- Comment By: Peter Klotz (pete_icoserve) Date: 2005-10-12 00:01 Message: Logged In: YES user_id=299547 Re: AMD64 compilers are available as part of the current platform SDK as available to MSDN subscribers (not through the free SDK download), and also reportedly available as part of the DDK. It is true that the current platform SDK supports AMD64 but the included compiler has version number 14.00 and comes with the same C runtime that is shipped with VS2005. I should have stated 'there is no AMD64 support prior to cl 14.00' rather than 'there is no AMD64 support prior to VS2005'. Nevertheless if you have to compile for AMD64 under Windows you have to use cl 14.00 and you cannot avoid the C runtime library showing the new signal behavior. -- Comment By: Adal Chiriliuc (adalx) Date: 2005-10-11 17:17 Message: Logged In: YES user_id=1067739 This has been reported before. Maybe these two bugs should me merged somehow: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167262&group_id=5470 The older bug report states that it's an assertion error, not a crash. That's consistent with the recent security clean-up of the CRT in VS 2005. I don't think that MS will fix this, since they are the ones w
[ python-Bugs-1385055 ] execfile anomaly with "from __future__ import division"
Bugs item #1385055, was opened at 2005-12-19 02:15
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1385055&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Harri Pasanen (harripasanen)
Assigned to: Nobody/Anonymous (nobody)
Summary: execfile anomaly with "from __future__ import division"
Initial Comment:
If I have a file init.py with two lines:
from __future__ import division
print 3/4
and I do
[EMAIL PROTECTED] tests]$ python
Python 2.4 (#1, Feb 16 2005, 01:23:25)
[GCC 3.4.3 (Mandrakelinux 10.0 3.4.3-2mdk)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> execfile('init.py')
0.75
>>> 3/4
0
I would have expected the latter to return 0.75 as
well.
Due to this it seems impossible to provide init code
that would initialize the interactive prompt to
future division behaviour.
The same applies to exec statement.
I'm not sure if this is bug, or an unfortunate
feature. The documention is not very clear on this
issue.
-Harri
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-20 21:53
Message:
Logged In: YES
user_id=33168
Closing per your request. I don't see any particularly good
place in the doc to add a comment. I agree a comment about
-Qnew wouldn't hurt.
--
Comment By: Harri Pasanen (harripasanen)
Date: 2005-12-19 02:42
Message:
Logged In: YES
user_id=77088
Looks like this is a duplicate of
[ 567568 ] future division broken w/ PYTHONSTARTUP
http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=567568
As I suspected, it is an unfortunate feature. Tim's
explication provides the missing documentation. And I
assume the exec statement provides its own anonymous
module.
Btw. where is the -Qnew documented? from __future__
division docs should carry a pointer to it.
Here is another thread on the subject in the ipython
mailing list:
http://scipy.net/pipermail/ipython-user/2005-December/001183.html
This can be closed.
-Harri
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1385055&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
