[ python-Bugs-1557232 ] Parser crash
Bugs item #1557232, was opened at 2006-09-12 15:28 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557232&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: Parser/Compiler Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Parser crash Initial Comment: The code def x(((y))):pass crashes the compiler (?) in 2.5c2, on Windows. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-25 07:05 Message: Logged In: YES user_id=849994 Backported in rev. 51999. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-22 08:21 Message: Logged In: YES user_id=33168 Committed revision 51972. (2.6) Still needs backport. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-18 05:55 Message: Logged In: YES user_id=33168 Attaching a new patch with tests. There probably should be more tests, but this is all I can think of at this point. I think I've covered the cases of the recursive definition properly now. Conceptually this is a very small patch. I've added a bunch of asserts and broken some complex lines up though. The first chunk deals with complex_args and elides superfluous parens around (x). The second chunk does the same eliding but for non-complex args. Any number of extra parens should be elided properly now. I will apply to head and 2.5.1 later. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-13 07:44 Message: Logged In: YES user_id=33168 I think patch v2 might fix both problems. I'm not sure it's correct. We really need a lot of tests for this stuff. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-13 06:22 Message: Logged In: YES user_id=33168 The attached patch seems to fix the x problem. I didn't run in debug mode, so I'm not positive the assert works as I expect. However now my test case below doesn't work, it puts in 5 UNPACK_SEQUENCES rather than 3. This looks like a different problem in compiler_complex_args(). Not sure how much farther I'll get tonight. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-13 06:00 Message: Logged In: YES user_id=33168 I guess what 2.4 does is the most reasonable behavior: >>> def f((x)),),),)): pass >>> dis.dis(f) 1 0 LOAD_FAST0 (.0) 3 UNPACK_SEQUENCE 1 6 UNPACK_SEQUENCE 1 9 UNPACK_SEQUENCE 1 12 STORE_FAST 1 (x) 15 LOAD_CONST 0 (None) 18 RETURN_VALUE -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-13 05:50 Message: Logged In: YES user_id=33168 The problem is in Python/ast.c around line 666. See the comment: /* def foo((x)): setup for checking NAME below. */ The code is not sufficient, we need a loop and need to handle various combinations of: def f(x))),)),))): pass I don't know if the parens above match, but the general idea is that there could be a bunch of parens and commas at various places. I'm not sure how the above should be interpreted. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557232&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1565071 ] update Lib/plat-linux2/IN.py
Bugs item #1565071, was opened at 2006-09-25 14:51 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=1565071&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: update Lib/plat-linux2/IN.py Initial Comment: there's a request to update this module to add missing IN.SIO* definitions. How should that be done? Just re-running h2py drops all SIO* definitions, because the linux/sockios.h header isn't included anymore. requested at http://launchpad.net/bugs/58081 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565071&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1565087 ] Misbehaviour in zipfile
Bugs item #1565087, was opened at 2006-09-25 13:15 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=1565087&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Richard Philips (rphilips) Assigned to: Nobody/Anonymous (nobody) Summary: Misbehaviour in zipfile Initial Comment: Python 2.5 In library module zipfile, a ZipFile object has method write( filename[, arcname[, compress_type]]) If arcname is not specified, it defaults to the pathname of filename without a drive letter and with leading path separators removed. That is OK. But if arcname is explicitely specified, the drive letter and leading path separators are also removed. I think that is not OK. thanks, Richard Philips -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565087&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1565129 ] make plistlib.py available in every install
Bugs item #1565129, was opened at 2006-09-25 16:28 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=1565129&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: make plistlib.py available in every install Initial Comment: [requested in http://bugs.debian.org/386738] plistlib which is currently under ./Lib/plat-mac/plistlib.py is usefull on other platforms too it's e.g. needed for packaging calendar-server -- Apple's calendar server The module could be packaged separately, but should better be used from the standard library. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565129&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1565150 ] os.stat() subsecond file mode time is incorrect on Windows
Bugs item #1565150, was opened at 2006-09-25 11:08 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=1565150&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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike Glassford (glassfordm) Assigned to: Nobody/Anonymous (nobody) Summary: os.stat() subsecond file mode time is incorrect on Windows Initial Comment: Either the new ability of os.stat() to report subsecond file modification times, or the os.utime() function, appears to have a bug on Windows. The following script illustrates. The problem is that the decimal part of the modification time reported by os.stat() is always equal to the decimal part of what was passed to os.utime() divided by ten (and rounded). ###Begin Script import os strPath = "c:/test.xxx" #Create the file f = open(strPath, 'w') f.close() #Set the file mod time t1 = 1159195039.2 os.utime(strPath, (t1, t1)) #Get the file mod time t2 = os.stat(strPath).st_mtime print t1, t2 ###Sample output 1159195039.2 1159195039.02 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565150&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1565150 ] os.stat() subsecond file mode time is incorrect on Windows
Bugs item #1565150, was opened at 2006-09-25 11:08 Message generated for change (Comment added) made by glassfordm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565150&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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike Glassford (glassfordm) Assigned to: Nobody/Anonymous (nobody) Summary: os.stat() subsecond file mode time is incorrect on Windows Initial Comment: Either the new ability of os.stat() to report subsecond file modification times, or the os.utime() function, appears to have a bug on Windows. The following script illustrates. The problem is that the decimal part of the modification time reported by os.stat() is always equal to the decimal part of what was passed to os.utime() divided by ten (and rounded). ###Begin Script import os strPath = "c:/test.xxx" #Create the file f = open(strPath, 'w') f.close() #Set the file mod time t1 = 1159195039.2 os.utime(strPath, (t1, t1)) #Get the file mod time t2 = os.stat(strPath).st_mtime print t1, t2 ###Sample output 1159195039.2 1159195039.02 -- >Comment By: Mike Glassford (glassfordm) Date: 2006-09-25 11:10 Message: Logged In: YES user_id=963931 Sorry, although it can be inferred from the report, I should mention that this is with Python 2.5. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565150&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1565129 ] make plistlib.py available in every install
Bugs item #1565129, was opened at 2006-09-25 16:28 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565129&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: make plistlib.py available in every install Initial Comment: [requested in http://bugs.debian.org/386738] plistlib which is currently under ./Lib/plat-mac/plistlib.py is usefull on other platforms too it's e.g. needed for packaging calendar-server -- Apple's calendar server The module could be packaged separately, but should better be used from the standard library. -- Comment By: �iga Seilnacht (zseil) Date: 2006-09-25 17:42 Message: Logged In: YES user_id=1326842 This is a duplicate of bug #779460: http://www.python.org/sf/779460 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565129&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1563046 ] MacPython ignores user-installed Tcl/Tk
Bugs item #1563046, was opened at 2006-09-21 10:55 Message generated for change (Comment added) made by reowen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563046&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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: MacPython ignores user-installed Tcl/Tk Initial Comment: MacPython ignores any user-installed Framework Tcl/Tk. This is a significant issue for Tcl/Tk users because the Tcl/Tk included with Tiger is buggy and really shouldn't be used. Bob Ippolito supplied me a recipe to fix _tkinter.so: install_name_tool \ -change /System/Library/Frameworks/Tcl.framework/Versions/8.4/ Tcl \ /Library/Frameworks/Tcl.framework/Versions/8.4/Tcl \ -change /System/Library/Frameworks/Tk.framework/Versions/8.4/ Tk \ /Library/Frameworks/Tk.framework/Versions/8.4/Tk \ _tkinter.so I encapsulated this recipe into the attached python script "fixtkinter.py", which modifies _tkinter.so to use the user's Tcl/Tk, if found. Please consider running this script while installing MacPython. If you want any refinements to the script, I am happy to provide them (or feel free to modify it yourself of course). Subtleties: - The script uses Carbon.Folder.FSFindFolder to find the "/Library/ Framework" directory, so it should work in any country. - The script fixes the _tkinter.so for the python that executes the script (finding it relative to the "os" module). - The script silently exits without doing anything if no /Library/ Framework Tcl/Tk is found. Thus it is safe to run for all MacPython installations. - It can safely be run more than once; it silently does not modify _tkinter.so file the second time. - It finds the link using ...Tcl.Framework/Versions/Current but resolves the link before modifying _tkinter.so. So if a user upgrades a major Tcl/ Tk version the _tkinter.so file will keep using the old version. I think this is a good thing, since compatilibility is likely to be an issue. - It only looks for a user-installed Tcl/Tk in "/Library/Frameworks"; it does NOT look in the user's private library (~/Library). This was intentional, but I'm not sure it was the right decision. I'm happy to change it, but will want some advice on the best algorithm. -- >Comment By: Russell Owen (reowen) Date: 2006-09-25 13:43 Message: Logged In: YES user_id=431773 I see what you mean about different installations. I think the following might work better: - Always modify _tkinter.so to point to Tcl/Tk 8.4 in /Library/Frameworks. This will fall back to the built in /System/Library/Frameworks if the user has not installed an 8.4 of their own. It avoids a few of the issues you bring up and is simpler and more robust than what I originally suggested. Advantages: - All installations would be the same. - If the user installs a new Tcl/Tk after installing Python, it would be used (unless it's 8.5, which would not be safe to try with Python). It still does not address your concern than a user might accidentally have a Tcl/Tk that they don't want to use. I'd personally be happier if users could easily upgrade their Tcl/Tk (since the installed one is so bad), so I see this as more of an advantage than a disadvantage. Users aren't going to typically install Tcl/Tk unless they want to use it, I think. Still...I'm sure you've seen more requests for help than I have over the years. I'm not keen on including a Tcl/Tk for several reasons: - It can be tricky to add needed additions (my app uses the "snack" sound library, for example). A standard Tcl/Tk makes this much easier (and in fact ActiveState Tcl/Tk already includes all additions most folks would want). - There is no universal Tcl/Tk yet (though one is planned). I personally don't want to try to build one. - Which version would you use? Even 8.4.11 has some important known bugs, and 8.4.13 has different ones (at least one of which is very nasty for my application, so I stick with 8.4.11 for now). So my personal suggestion is that we modify _tkinter.so using Bob Ippolito's recipe unchanged (no fancy script that hunts for an installed Tcl/Tk). It will be completely compatible with the built in Tcl/Tk but gives any real users of Tcl/ Tk (anyone who isn't just writing "hello world") a trivial way to get a decent version. I also suggest ditching the python script (or simplifying it to just institute Bob's recipe, but a shell script probably makes more sense for that job). Note that Bob's recipe is in the comments at the top of my python script. Thanks for the note about /Library/Frameworks. I had no idea it was a unive
[ python-Bugs-1564763 ] Unicode comparison change in 2.4 vs. 2.5
Bugs item #1564763, was opened at 2006-09-24 23:43 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1564763&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: Unicode Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Joe Wreschnig (piman) Assigned to: M.-A. Lemburg (lemburg) Summary: Unicode comparison change in 2.4 vs. 2.5 Initial Comment: Python 2.5 changed the behavior of unicode comparisons in a significant way from Python 2.4, causing a test case failure in a module of mine. All tests passed with an earlier version of 2.5, though unfortunately I don't know what version in particular it started failing with. The following code prints out all True on Python 2.4; the strings are compared case-insensitively, whether they are my lowerstr class, real strs, or unicodes. On Python 2.5, the comparison between lowerstr and unicode is false, but only in one direction. If I make lowerstr inherit from unicode rather than str, all comparisons are true again. So at the very least, this is internally inconsistent. I also think changing the behavior between 2.4 and 2.5 constitutes a serious bug. -- >Comment By: Armin Rigo (arigo) Date: 2006-09-25 21:11 Message: Logged In: YES user_id=4771 This is an artifact of the change in the unicode class, which now has the proper __eq__, __ne__, __lt__, etc. methods instead of the semi-deprecated __cmp__. The mixture of __cmp__ and the other methods is not very well-defined. This is why your code worked in 2.4: a bit by chance. Indeed, in theory it should not, according to the language reference. So what I am saying is that although it is a behavior change from 2.4 to 2.5, I would argue that it is not a bug but a bug fix... The reason is that if we ignore the __eq__ vs __cmp__ issues, the operation 'a == b' is defined as: Python tries a.__eq__(b); if this returns NotImplemented, then Python tries b.__eq__(a). As an exception, if type(b) is a strict subclass of type(a), then Python tries in the other order. This is why you get the 2.5 behavior: if lowerstr inherits from str, it is not a subclass of unicode, so u'abc' == lowerstr() tries u'abc'.__eq__(), which works immediately. On the other hand, if lowerstr inherits from unicode, then Python tries first lowerstr().__eq__(u'abc'). This part of the Python object model - when to reverse the order or not - is a bit obscure and not completely helpful... Subclassing built-in types generally only works a bit. In your situation you should use a regular class that behaves in a string-like fashion, with an __eq__() method doing the case-insensitive comparison... if you can at all - there are places where you need a real string, so this "solution" might not be one either, but I don't see a better one :-( -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1564763&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1564763 ] Unicode comparison change in 2.4 vs. 2.5
Bugs item #1564763, was opened at 2006-09-24 23:43
Message generated for change (Comment added) made by arigo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1564763&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: Unicode
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Joe Wreschnig (piman)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Unicode comparison change in 2.4 vs. 2.5
Initial Comment:
Python 2.5 changed the behavior of unicode comparisons
in a significant way from Python 2.4, causing a test
case failure in a module of mine. All tests passed with
an earlier version of 2.5, though unfortunately I don't
know what version in particular it started failing with.
The following code prints out all True on Python 2.4;
the strings are compared case-insensitively, whether
they are my lowerstr class, real strs, or unicodes. On
Python 2.5, the comparison between lowerstr and unicode
is false, but only in one direction.
If I make lowerstr inherit from unicode rather than
str, all comparisons are true again. So at the very
least, this is internally inconsistent. I also think
changing the behavior between 2.4 and 2.5 constitutes a
serious bug.
--
>Comment By: Armin Rigo (arigo)
Date: 2006-09-25 21:33
Message:
Logged In: YES
user_id=4771
Sorry, I missed your comment: if lowerstr inherits from
unicode then it just works. The reason is that
'abc'.__eq__(u'abc') returns NotImplemented, but
u'abc'.__eq__('abc') returns True.
This is only inconsistent because of the asymmetry between
strings and unicodes: strings can be transparently turned
into unicodes but not the other way around -- so
unicode.__eq__(x) can accept a string as the argument x
and convert it to a unicode transparently, but str.__eq__(x)
does not try to convert x to a string if it is a unicode.
It's not a completely convincing explanation, but I think it
shows at least why we got at the current situation of Python
2.5.
--
Comment By: Armin Rigo (arigo)
Date: 2006-09-25 21:11
Message:
Logged In: YES
user_id=4771
This is an artifact of the change in the unicode class, which
now has the proper __eq__, __ne__, __lt__, etc. methods
instead of the semi-deprecated __cmp__. The mixture of
__cmp__ and the other methods is not very well-defined. This
is why your code worked in 2.4: a bit by chance.
Indeed, in theory it should not, according to the language
reference. So what I am saying is that although it is a
behavior change from 2.4 to 2.5, I would argue that it is not
a bug but a bug fix...
The reason is that if we ignore the __eq__ vs __cmp__ issues,
the operation 'a == b' is defined as: Python tries
a.__eq__(b); if this returns NotImplemented, then Python
tries b.__eq__(a). As an exception, if type(b) is a strict
subclass of type(a), then Python tries in the other order.
This is why you get the 2.5 behavior: if lowerstr inherits
from str, it is not a subclass of unicode, so u'abc' ==
lowerstr() tries u'abc'.__eq__(), which works immediately.
On the other hand, if lowerstr inherits from unicode, then
Python tries first lowerstr().__eq__(u'abc').
This part of the Python object model - when to reverse the
order or not - is a bit obscure and not completely helpful...
Subclassing built-in types generally only works a bit. In
your situation you should use a regular class that behaves in
a string-like fashion, with an __eq__() method doing the
case-insensitive comparison... if you can at all - there are
places where you need a real string, so this "solution" might
not be one either, but I don't see a better one :-(
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1564763&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1565150 ] os.stat() subsecond file mode time is incorrect on Windows
Bugs item #1565150, was opened at 2006-09-25 08:08 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565150&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: None >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Mike Glassford (glassfordm) Assigned to: Nobody/Anonymous (nobody) Summary: os.stat() subsecond file mode time is incorrect on Windows Initial Comment: Either the new ability of os.stat() to report subsecond file modification times, or the os.utime() function, appears to have a bug on Windows. The following script illustrates. The problem is that the decimal part of the modification time reported by os.stat() is always equal to the decimal part of what was passed to os.utime() divided by ten (and rounded). ###Begin Script import os strPath = "c:/test.xxx" #Create the file f = open(strPath, 'w') f.close() #Set the file mod time t1 = 1159195039.2 os.utime(strPath, (t1, t1)) #Get the file mod time t2 = os.stat(strPath).st_mtime print t1, t2 ###Sample output 1159195039.2 1159195039.02 -- Comment By: Mike Glassford (glassfordm) Date: 2006-09-25 08:10 Message: Logged In: YES user_id=963931 Sorry, although it can be inferred from the report, I should mention that this is with Python 2.5. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565150&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1565509 ] Repair or Change installation error
Bugs item #1565509, was opened at 2006-09-26 05:34 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=1565509&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: Installation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: Repair or Change installation error Initial Comment: When I re-run the Python 2.5 final installer and choose either Repair or Change options, it makes it to the "Publish product information" step then says: "A network error occurred while attempting to read from the file: C:\Documents and Settings\username\Desktop\python-2.5 [1].msi" The thing is, I saved the file as python-2.5.msi and the file it mentions does not exist. If I copy python- 2.5.msi to python-2.5[1].msi, then run python-2.5.msi, the installation works! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565509&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1565514 ] does not raise SystemError on too many nested blocks
Bugs item #1565514, was opened at 2006-09-26 06:10 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=1565514&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: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: does not raise SystemError on too many nested blocks Initial Comment: Simple script attached, in python 2.4.3 I get reasonable results: C:\>.\python24\python.exe nested.py File "nested.py", line 22 while 22: SystemError: too many statically nested blocks C:\> However in python 2.5 I get nothing: C:\>.\python25\python.exe nested.py C:\> Shouldn't the same error be raised? (Note that it's not executing the file, or the prints would occur). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565514&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1565525 ] gc allowing tracebacks to eat up memory
Bugs item #1565525, was opened at 2006-09-26 06:58 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=1565525&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: gc allowing tracebacks to eat up memory Initial Comment: Attached is a file which demonstrates an oddity about traceback objects and the gc. The observed behaviour is that when the tuple from sys.exc_info() is stored on an object which is inside the local scope, the object, thus exc_info tuple, are not collected even when both leave scope. If you run the test with "s.e = sys.exc_info()" commented out, the observed memory footprint of the process quickly approaches and sits at 5,677,056 bytes. Totally reasonable. If you uncomment that line, the memory footprint climbs to 283,316,224 bytes quite rapidly. That's a two order of magnitude difference! If you uncomment the "gc.collect()" line, the process still hits 148,910,080 bytes. This was observed in production code, where exc_info tuples are saved for re-raising later to get the stack- appending behaviour tracebacks and 'raise' perform. The example includes a large array to simulate application state. I assume this is bad behaviour occurring because the traceback object holds frames, and those frames hold a reference to the local objects, thus the exc_info tuple itself, thus causing a circular reference which involves the entire stack. Either the gc needs to be improved to prevent this from growing so wildly, or the traceback objects need to (optionally?) hold frames which do not have references or have weak references instead. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565525&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
