[ python-Bugs-1666807 ] Incorrect file path reported by inspect.getabsfile()
Bugs item #1666807, was opened at 2007-02-23 08:08 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666807&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: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Fernando P�rez (fer_perez) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect file path reported by inspect.getabsfile() Initial Comment: The following code demonstrates the problem succinctly: ### import inspect,sys print 'Version info:',sys.version_info print f1 = inspect.getabsfile(inspect) f2 = inspect.getabsfile(inspect.iscode) print 'File for `inspect` :',f1 print 'File for `inspect.iscode`:',f2 print 'Do these match?',f1==f2 if f1==f2: print 'OK' else: print 'BUG - this is a bug in this version of Python' ### EOF Running this on my system (Linux, Ubuntu Edgy) with 2.3, 2.4 and 2.5 produces: tlon[bin]> ./python2.3 ~/code/python/inspect_bug.py Version info: (2, 3, 6, 'final', 0) File for `inspect` : /home/fperez/tmp/local/lib/python2.3/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/lib/python2.3/inspect.py Do these match? True OK tlon[bin]> python2.4 ~/code/python/inspect_bug.py Version info: (2, 4, 4, 'candidate', 1) File for `inspect` : /usr/lib/python2.4/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/bin/inspect.py Do these match? False BUG - this is a bug in this version of Python tlon[bin]> python2.5 ~/code/python/inspect_bug.py Version info: (2, 5, 0, 'final', 0) File for `inspect` : /usr/lib/python2.5/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/bin/inspect.py Do these match? False BUG - this is a bug in this version of Python ### The problem arises in the fact that inspect relies, for functions (at least), on the func_code.co_filename attribute to contain a complete path. This changed between 2.3 and 2.4, but the inspect module was never updated. This code: ### import inspect,sys print 'Python version info:',sys.version_info print 'File info for `inspect.iscode function`:' print ' ',inspect.iscode.func_code.co_filename print ### EOF shows the problem: tlon[bin]> ./python2.3 ~/code/python/inspect_bug_details.py Python version info: (2, 3, 6, 'final', 0) File info for `inspect.iscode function`: /home/fperez/tmp/local//lib/python2.3/inspect.py tlon[bin]> python2.5 ~/code/python/inspect_bug_details.py Python version info: (2, 5, 0, 'final', 0) File info for `inspect.iscode function`: inspect.py ### (2.4 has the same issue). Basically, if the func_code.co_filename attribute now stores only the final filename without the full path, then the logic in the inspect module needs to be changed to accomodate this so that correct paths are reported to the user like they were in the 2.3 days. -- >Comment By: Žiga Seilnacht (zseil) Date: 2007-04-03 09:15 Message: Logged In: YES user_id=1326842 Originator: NO Ok, this is the same problem as reported in bug #1180193: http://www.python.org/sf/1180193 The reporter of that bug is willing to write a patch, so I think it is better to close this one as a duplicate. -- Comment By: Fernando P�rez (fer_perez) Date: 2007-03-19 00:49 Message: Logged In: YES user_id=395388 Originator: YES Yes, though at least in this report we seem to have narrowed down the problem a little better. I'm perfectly willing to believe that Ubuntu is somehow mis-building their shipped Python, but it would be great if the Python build itself could be hardened against this being possible in the first place. Unfortunately I don't know how to better track the problem, but I'll be glad to provide info from my local system upon request. -- Comment By: Žiga Seilnacht (zseil) Date: 2007-03-16 15:06 Message: Logged In: YES user_id=1326842 Originator: NO It looks like this is a bug in Ubuntu build process. The logging package had the same problem: http://www.python.org/sf/1669498 http://www.python.org/sf/1633605 http://www.python.org/sf/1616422 -- Comment By: Fernando P�rez (fer_perez) Date: 2007-03-09 03:00 Message: Logged In: YES user_id=395388 Originator: YES As I mentioned, on hand-built Pythons I don't get the bug at all. So it may be a problem with how Ubuntu builds its Python, since I can reproduce the problem with both 2.4 and 2.5, but only with the default ones provided by Ubuntu Edgy. I don't know enough about their packaging system to know how to retrieve build info. There may be somet
[ python-Bugs-1051638 ] incorrect traceback filename from pyc
Bugs item #1051638, was opened at 2004-10-21 19:24 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1051638&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.3 >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Kevin Quick (kquick) Assigned to: Nobody/Anonymous (nobody) Summary: incorrect traceback filename from pyc Initial Comment: The .pyc file apparently caches the entire path of the source file during compilation, causing it to report improper path information if the resulting code is moved and an exception occurs. $ python Python 2.3.3 (#1, Oct 18 2004, 16:10:24) [GCC 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> -- >Comment By: Žiga Seilnacht (zseil) Date: 2007-04-03 09:16 Message: Logged In: YES user_id=1326842 Originator: NO This is a duplicate of bug #1180193: http://www.python.org/sf/1180193 -- Comment By: Kevin Quick (kquick) Date: 2004-10-30 08:01 Message: Logged In: YES user_id=6133 OK, I've done some more investigation and have some more details and clarification. I've attached another python script that demonstrates these additional clarifications: First, it runs sample scripts in a test directory. The sample scripts generate an exception, print that exception with traceback.print_exc, then raise to let the interpreter print the exception as it fails the script. The control script verifies that the output of traceback.print_exc matches the interpreter's traceback output. So far, so good. Step two demonstrates the first problem: the original directory is simply renamed; the previous location does not exist. The same sample scripts are run, and the output now shows that traceback.print_exc() output is *different* than the interpreter's traceback. Specifically, the interpreter prints the new, correct path, but the traceback.print_exc() prints the old path. Step three demonstrates another problem. The scripts are run from the new directory, but the old directory now exists, along files having the original .py names, but those files are now much shorter; the lines that will be referenced in the traceback do not exist. In the output from this step, note that the output from traceback.print_exc() and the interpreter traceback are again *different* from each other. In this case, both are fooled into reporting file paths in the old directory, but for a non-existent line the interpreter prints a blank line but traceback.print_exc() doesn't print a line at all. And finally, the .py files in the original directory are filled with nonsense (in python terms). This test case shows that the output from traceback. print_exc() and the interpreter *do match*, but both are fooled into showing file paths in the old directory and the nonsense from the new versions of the files. IMHO, I think that the output from the traceback.print_exc() and the interpreter traceback should be the same in *all* scenarios, and I also think that the path used for importing the module should be used in traceback reporting. Rather than encoding the full path of the .py source in the .pyc, the compiler should just encode the name portion, and use the path from the .pyc import and look for the .py in the same directory as the .pyc; if that's garbage, then so be it, but this will 99% of the time be more correct than the current behavior. -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-24 02:40 Message: Logged In: YES user_id=80475 IMO, this is not a bug. A pyc file has no way of knowing the future locations of the source that originally created it. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1051638&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1180193 ] broken pyc files
Bugs item #1180193, was opened at 2005-04-10 15:10 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180193&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: broken pyc files Initial Comment: In a number of situations, the .pyc files can become "corrupted" in a subtle way: the co_filename attribute of the code objects it contains become wrong. This can occur if we move or rename directories, or if we access the same set of files from two different locations (e.g. over NFS). This corruption doesn't prevent the .pyc files from working, but the interpreter looses the reference to the source file. It causes trouble in tracebacks, in the inspect module, etc. A simple fix would be to use the following logic when importing a .py file: if there is a corresponding .pyc file, in addition to checking the timestamp, check the co_filename attribute of the loaded object. If it doesn't point to the original .py file, discard the code object and ignore the .pyc file. Alternatively, we could force all co_filenames to point to the .py file when loading the .pyc file. I'll write a patch for whichever alternative seems better. -- >Comment By: Žiga Seilnacht (zseil) Date: 2007-04-03 09:16 Message: Logged In: YES user_id=1326842 Originator: NO This problem is reported quite often in the tracker, although it shows up in different places: http://www.python.org/sf/1666807 http://www.python.org/sf/1051638 I closed those bugs as duplicates of this one. The logging package is also affected: http://www.python.org/sf/1669498 http://www.python.org/sf/1633605 http://www.python.org/sf/1616422 -- Comment By: Armin Rigo (arigo) Date: 2007-03-28 15:40 Message: Logged In: YES user_id=4771 Originator: YES What I called "corruption" is the situation where both the .py and the .pyc files are present, but the filename stored in the .pyc co_filenames is no longer the valid absolute path of the corresponding .py file, for any reason (renaming, NFS views, etc.). This situation causes the tracebacks and the inspect module to fail to locate the .py file, which I consider a bug. -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-28 14:01 Message: Logged In: YES user_id=21627 Originator: NO I fail to see the corruption. It is quite desirable and normal to only ship pyc files - that the file name they refer to is actually present is not a requirement at all. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180193&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1508369 ] logging module formatter problem with %(filename)s
Bugs item #1508369, was opened at 2006-06-19 04:08 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508369&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.4 Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: David Hess (david_k_hess) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: logging module formatter problem with %(filename)s Initial Comment: With Python 2.4.3 installed via the .dmg on to MacOS, when the python modules are compiled, they are compiled by specifying the path in such a way that it contains a double slash. This causes the logging module to not be able to figure out which module is the correct one to replace for % (filename)s. The following is the crux of the issue: >>> logging.debug.func_code.co_filename '/Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/ logging/__init__.py' >>> logging.__file__ '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/ logging/__init__.pyc' >>> These two strings need to match for %(filename)s to work. I deleted /Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/logging/__init__.pyc and recompiled it by just importing logging. That fixed the problem. I assume the fix will be in the installer somewhere. -- >Comment By: Žiga Seilnacht (zseil) Date: 2007-04-03 09:46 Message: Logged In: YES user_id=1326842 Originator: NO The 2.4 branch is not maintained anymore. Can this bug be closed? -- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-06-25 23:16 Message: Logged In: YES user_id=580910 Fixed in revision #47093 for python2.5. I'm not closing the bug yet because I haven't backported this to 2.4 yet. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508369&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1671137 ] slice obj with no start index is 0 instead of None sometimes
Bugs item #1671137, was opened at 2007-02-28 11:58
Message generated for change (Comment added) made by jyzude
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671137&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.6
>Status: Closed
Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Mike Verdone (jyzude)
Assigned to: Nobody/Anonymous (nobody)
Summary: slice obj with no start index is 0 instead of None sometimes
Initial Comment:
Slice objects returned by the slice ":42" return different slice objects
depending on whether the entire slice operation is simple or extended. This bit
of code explains it best:
class SliceBug:
def __getitem__(self, sliceArg):
print sliceArg
s = SliceBug()
s[:42]
s[:42,]
s[:42] produces slice(0, 42, None)
s[:42,] produces (slice(None, 42, None),)
Note that this bug only occurs on classes that do no inherit from object ("old
style" classes). If you change the class to make it inherit from "object" both
slices have None as their start index. Oddly enough in Python 3000 it still
only happens on "old style" classes even though supposedly they are the same as
new style classes. I have also reproduced the bug in Python 2.6, 2.4, 2.3, and
2.2. Seems to be a long standing bug/feature.
--
>Comment By: Mike Verdone (jyzude)
Date: 2007-04-03 01:56
Message:
Logged In: YES
user_id=584997
Originator: YES
I concur. I'll close the bug.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2007-04-02 13:11
Message:
Logged In: YES
user_id=80475
Originator: NO
Fixing this small inconsistency has very little upside but runs the risk
of breaking code that has been running fine for years. I think we should
punt. If you agree, please close this bug report.
--
Comment By: Mike Verdone (jyzude)
Date: 2007-02-28 12:04
Message:
Logged In: YES
user_id=584997
Originator: YES
Correction! This is fixed in Python 3000. I just have too many windows
open and too many branches checked out.
File Added: slicebug.py
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671137&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1506296 ] Add some dicts to datetime module
Feature Requests item #1506296, was opened at 2006-06-14 21:35
Message generated for change (Comment added) made by zseil
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506296&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Gregory Petrosyan (gregory_p)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add some dicts to datetime module
Initial Comment:
I think it would be nice to have dicts like
weekdays = {0:'Monday', ...}
isoweekdays = {1:'Monday', ...}
months = {1:'January', ...}
in the datetime module. IMO they are rather usefull.
--
Regards, Gregory.
--
>Comment By: Ziga Seilnacht (zseil)
Date: 2007-04-03 10:44
Message:
Logged In: YES
user_id=1326842
Originator: NO
The calendar module already has something similar;
calendar.day_name, calendar.day_abbr,
calendar.month_name, calendar.month_abbr.
If you think there is still something missing, it
would be better to add it there.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506296&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1180193 ] broken pyc files
Bugs item #1180193, was opened at 2005-04-10 13:10 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180193&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: broken pyc files Initial Comment: In a number of situations, the .pyc files can become "corrupted" in a subtle way: the co_filename attribute of the code objects it contains become wrong. This can occur if we move or rename directories, or if we access the same set of files from two different locations (e.g. over NFS). This corruption doesn't prevent the .pyc files from working, but the interpreter looses the reference to the source file. It causes trouble in tracebacks, in the inspect module, etc. A simple fix would be to use the following logic when importing a .py file: if there is a corresponding .pyc file, in addition to checking the timestamp, check the co_filename attribute of the loaded object. If it doesn't point to the original .py file, discard the code object and ignore the .pyc file. Alternatively, we could force all co_filenames to point to the .py file when loading the .pyc file. I'll write a patch for whichever alternative seems better. -- >Comment By: Armin Rigo (arigo) Date: 2007-04-03 11:31 Message: Logged In: YES user_id=4771 Originator: YES If you ask me, I think that when the importing system finds both a .py and a .pyc for a module, then it should ignore all co_filename and replace them with the real path of the .py file. I can't see any point of not doing so. There are many other quirks caused by .pyc files accidentally remaining around, but we cannot fix them all as long as the .pyc files are at the same time a cache for performance reason and a redistributable program format (e.g. if "rm x.py" or "svn up" deletes a .py file, then the module is still importable via the .pyc left behind, a great way to oversee the fact that imports elsewhere in the project need to be updated). -- Comment By: Ziga Seilnacht (zseil) Date: 2007-04-03 07:16 Message: Logged In: YES user_id=1326842 Originator: NO This problem is reported quite often in the tracker, although it shows up in different places: http://www.python.org/sf/1666807 http://www.python.org/sf/1051638 I closed those bugs as duplicates of this one. The logging package is also affected: http://www.python.org/sf/1669498 http://www.python.org/sf/1633605 http://www.python.org/sf/1616422 -- Comment By: Armin Rigo (arigo) Date: 2007-03-28 13:40 Message: Logged In: YES user_id=4771 Originator: YES What I called "corruption" is the situation where both the .py and the .pyc files are present, but the filename stored in the .pyc co_filenames is no longer the valid absolute path of the corresponding .py file, for any reason (renaming, NFS views, etc.). This situation causes the tracebacks and the inspect module to fail to locate the .py file, which I consider a bug. -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-28 12:01 Message: Logged In: YES user_id=21627 Originator: NO I fail to see the corruption. It is quite desirable and normal to only ship pyc files - that the file name they refer to is actually present is not a requirement at all. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180193&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1693546 ] email.Message set_param rfc2231 encoding incorrect
Bugs item #1693546, was opened at 2007-04-03 14:13 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=1693546&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Anders Hammarquist (iko) Assigned to: Nobody/Anonymous (nobody) Summary: email.Message set_param rfc2231 encoding incorrect Initial Comment: Reading the ABNF for the extended parameter values in RFC2231 reveals that they should not be quoted: extended-initial-value := [charset] "'" [language] "'" extended-other-values extended-other-values := *(ext-octet / attribute-char) however, set_param (really _formatparam) will always quote them unless requote is set to false. The fix is probably to force quote in _formatparam to False if faced with RFC2231 values, since they should never be quoted (and should not contain characters requiring quoting), -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1693546&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1180193 ] broken pyc files
Bugs item #1180193, was opened at 2005-04-10 15:10 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180193&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: broken pyc files Initial Comment: In a number of situations, the .pyc files can become "corrupted" in a subtle way: the co_filename attribute of the code objects it contains become wrong. This can occur if we move or rename directories, or if we access the same set of files from two different locations (e.g. over NFS). This corruption doesn't prevent the .pyc files from working, but the interpreter looses the reference to the source file. It causes trouble in tracebacks, in the inspect module, etc. A simple fix would be to use the following logic when importing a .py file: if there is a corresponding .pyc file, in addition to checking the timestamp, check the co_filename attribute of the loaded object. If it doesn't point to the original .py file, discard the code object and ignore the .pyc file. Alternatively, we could force all co_filenames to point to the .py file when loading the .pyc file. I'll write a patch for whichever alternative seems better. -- >Comment By: Ziga Seilnacht (zseil) Date: 2007-04-03 15:46 Message: Logged In: YES user_id=1326842 Originator: NO Wouldn't your first solution be simpler? Changing all co_filenames would require either changing various marhal.c functions, or traversing the code object returned by import.c/read_compiled_module(). Discarding the compiled code when the file names don't match would be simpler and only require minor changes in import.c/load_source_module(). -- Comment By: Armin Rigo (arigo) Date: 2007-04-03 13:31 Message: Logged In: YES user_id=4771 Originator: YES If you ask me, I think that when the importing system finds both a .py and a .pyc for a module, then it should ignore all co_filename and replace them with the real path of the .py file. I can't see any point of not doing so. There are many other quirks caused by .pyc files accidentally remaining around, but we cannot fix them all as long as the .pyc files are at the same time a cache for performance reason and a redistributable program format (e.g. if "rm x.py" or "svn up" deletes a .py file, then the module is still importable via the .pyc left behind, a great way to oversee the fact that imports elsewhere in the project need to be updated). -- Comment By: Ziga Seilnacht (zseil) Date: 2007-04-03 09:16 Message: Logged In: YES user_id=1326842 Originator: NO This problem is reported quite often in the tracker, although it shows up in different places: http://www.python.org/sf/1666807 http://www.python.org/sf/1051638 I closed those bugs as duplicates of this one. The logging package is also affected: http://www.python.org/sf/1669498 http://www.python.org/sf/1633605 http://www.python.org/sf/1616422 -- Comment By: Armin Rigo (arigo) Date: 2007-03-28 15:40 Message: Logged In: YES user_id=4771 Originator: YES What I called "corruption" is the situation where both the .py and the .pyc files are present, but the filename stored in the .pyc co_filenames is no longer the valid absolute path of the corresponding .py file, for any reason (renaming, NFS views, etc.). This situation causes the tracebacks and the inspect module to fail to locate the .py file, which I consider a bug. -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-28 14:01 Message: Logged In: YES user_id=21627 Originator: NO I fail to see the corruption. It is quite desirable and normal to only ship pyc files - that the file name they refer to is actually present is not a requirement at all. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180193&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1669349 ] make install fails if no previous Python installation
Bugs item #1669349, was opened at 2007-02-26 15:22
Message generated for change (Comment added) made by sbassi
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669349&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
Private: No
Submitted By: Matthias S. Benkmann (mbenkmann)
Assigned to: Nobody/Anonymous (nobody)
Summary: make install fails if no previous Python installation
Initial Comment:
When installing Python 2.5 on a completely Python-less system 'make install'
failed. The error that caused the failure was
Compiling /usr/lib/python2.5/test/test_multibytecodec.py ...
Sorry: UnicodeError: ("\\N escapes not supported (can't load unicodedata
module)",)
[snip]
Compiling /usr/lib/python2.5/zipfile.py ...
make: *** [libinstall] Error 1
'find -name unicodedata.so' showed me that the library did not exist in the
build tree. However, after a 'make -i install' to force make to continue
despite the error, unicodedata.so was there. So apparently the library is not
built until a later stage of make install. And indeed, subsequent 'make
install' calls without -i were successful.
It is important to note that if you have a previous Python installation (at
least of the same version), 'make install' will go through, because it'll load
the library from there. So if you want to reproduce the issue you will have to
install from a freshly unpacked tarball on a system with no Python installation.
--
Comment By: Sebastian Bassi (sbassi)
Date: 2007-04-03 12:05
Message:
Logged In: YES
user_id=179653
Originator: NO
The same problem arises when installing Python using "make altinstall",
even with another Python installed.
--
Comment By: Simon Percivall (percivall)
Date: 2007-03-21 08:26
Message:
Logged In: YES
user_id=329382
Originator: NO
It shouldn't be a problem changing the Makefile to do sharedinstall before
libinstall in the altinstall target. I'm guessing that would solve the
problem.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669349&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1669349 ] make install fails if no previous Python installation
Bugs item #1669349, was opened at 2007-02-26 15:22
Message generated for change (Comment added) made by sbassi
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669349&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
Private: No
Submitted By: Matthias S. Benkmann (mbenkmann)
Assigned to: Nobody/Anonymous (nobody)
Summary: make install fails if no previous Python installation
Initial Comment:
When installing Python 2.5 on a completely Python-less system 'make install'
failed. The error that caused the failure was
Compiling /usr/lib/python2.5/test/test_multibytecodec.py ...
Sorry: UnicodeError: ("\\N escapes not supported (can't load unicodedata
module)",)
[snip]
Compiling /usr/lib/python2.5/zipfile.py ...
make: *** [libinstall] Error 1
'find -name unicodedata.so' showed me that the library did not exist in the
build tree. However, after a 'make -i install' to force make to continue
despite the error, unicodedata.so was there. So apparently the library is not
built until a later stage of make install. And indeed, subsequent 'make
install' calls without -i were successful.
It is important to note that if you have a previous Python installation (at
least of the same version), 'make install' will go through, because it'll load
the library from there. So if you want to reproduce the issue you will have to
install from a freshly unpacked tarball on a system with no Python installation.
--
Comment By: Sebastian Bassi (sbassi)
Date: 2007-04-03 12:50
Message:
Logged In: YES
user_id=179653
Originator: NO
Another workaround (by Jaroslaw Zabiello):
After executing
./configure
you have to edito
Modules/Setup
file and uncomment the following line:
#zlib zlibmodule.c -I$(prefix)/include -L$(exec_prefix)/lib -lz
Then continue with normal make; make install.
--
Comment By: Sebastian Bassi (sbassi)
Date: 2007-04-03 12:05
Message:
Logged In: YES
user_id=179653
Originator: NO
The same problem arises when installing Python using "make altinstall",
even with another Python installed.
--
Comment By: Simon Percivall (percivall)
Date: 2007-03-21 08:26
Message:
Logged In: YES
user_id=329382
Originator: NO
It shouldn't be a problem changing the Makefile to do sharedinstall before
libinstall in the altinstall target. I'm guessing that would solve the
problem.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669349&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1693753 ] Portability issie: os.rename behaves differently on win32
Bugs item #1693753, was opened at 2007-04-03 23:17 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=1693753&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: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: cs_ (cs_) Assigned to: Nobody/Anonymous (nobody) Summary: Portability issie: os.rename behaves differently on win32 Initial Comment: os.rename(src, dst) fails on Windows if dst already exist and regular file. On Unixes, it does not fail, and silently overwrites dst. It's better to use MoveFileEx(src, dst, MOVEFILE_REPLACE_EXISTING) when moving regular files under Win32 to make it behave consistent way. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1693753&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1657034 ] 'Ok' key in options dialog does nothing
Bugs item #1657034, was opened at 2007-02-11 01:35 Message generated for change (Comment added) made by torhu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1657034&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: IDLE Group: Python 2.5 >Status: Closed >Resolution: Works For Me Priority: 5 Private: No Submitted By: torhu (torhu) Assigned to: Nobody/Anonymous (nobody) Summary: 'Ok' key in options dialog does nothing Initial Comment: IDLE 1.2, winxp sp2 US. I get the same results with idlelib from svn rev. 53721. Steps to reproduce: 1. Open Options -> Configure IDLE... 2. Click on the Ok button. 3. Nothing happens, you have to click Cancel to close the options window. Here's a way that crashes IDLE on my machine: 1. Open Options -> Configure IDLE... 2. Set Indentation width to 8 (was 4 by default). 3. Click on Apply. 4. Click on Ok (nothing happens). 5. Click on Cancel - IDLE exits. Workaround: Replace the Python25/Lib/idlelib directory with the one that comes with python 2.4.3. -- >Comment By: torhu (torhu) Date: 2007-04-03 21:55 Message: Logged In: YES user_id=1038085 Originator: YES Reinstalling Windows seems to have fixed the problem for me. Not sure what caused it. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1657034&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1686597 ] descrintro: error describing __new__ behavior
Bugs item #1686597, was opened at 2007-03-23 03:47 Message generated for change (Comment added) made by bediviere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686597&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Gabriel Genellina (gagenellina) Assigned to: Nobody/Anonymous (nobody) Summary: descrintro: error describing __new__ behavior Initial Comment: descrintro (http://www.python.org/download/releases/2.2.3/descrintro/#__new__) linked from http://www.python.org/doc/newstyle/ still says: "__new__ must return an object. [...] If you return an object of a different class, its __init__ method will be called." But since Revision 26220 - Modified Sat Apr 6 01:05:01 2002 UTC (4 years, 11 months ago) by gvanrossum: "Changed new-style class instantiation so that when C's __new__ method returns something that's not a C instance, its __init__ is not called. [SF bug #537450]" That is, exactly the opposite as said on descrintro. The documentation for __new__ in the Reference manual, section 3.4.1, is correct and says: "If __new__() does not return an instance of cls, then the new instance's __init__() method will not be invoked." Note that the modified behavior was already present on version 2.2.3 (and later) so updating the document currently at /download/releases/2.2.3/ would be fine. -- Comment By: Steven Bethard (bediviere) Date: 2007-04-03 15:47 Message: Logged In: YES user_id=945502 Originator: NO Note that this is correct in the documentation: http://docs.python.org/ref/customization.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686597&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1684991 ] Explain __method__ lookup semantics for new-style classes
Bugs item #1684991, was opened at 2007-03-21 02:53 Message generated for change (Comment added) made by bediviere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1684991&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: Explain __method__ lookup semantics for new-style classes Initial Comment: __method__s (and next) are looked up on the type, not the instance. This isn't documented properly. -- Comment By: Steven Bethard (bediviere) Date: 2007-04-03 16:01 Message: Logged In: YES user_id=945502 Originator: NO This is not true for all __special__ methods, e.g. __enter__ and __exit__: >>> class C(object): ... pass ... >>> def enter(*args): ... print 'enter', args ... >>> def exit(*args): ... print 'exit', args ... >>> c = C() >>> c.__enter__ = enter >>> c.__exit__ = exit >>> with c: ... print 'hi' ... enter () hi exit (None, None, None) The documentation should say something like "When interpreting syntax that invokes a __special__ method, Python looks for the __special__ method on the instance's class. As an implementation detail, the lookup for some __special__ methods may also check the instance first, but this behavior should not be relied upon." This should probably go into the Reference Manual section 3.4: http://docs.python.org/ref/specialnames.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1684991&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1693941 ] Puzzled over list append bvehavior
Bugs item #1693941, was opened at 2007-04-03 15:44 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=1693941&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: elgordo (azgordo) Assigned to: Nobody/Anonymous (nobody) Summary: Puzzled over list append bvehavior Initial Comment: See attached IDLE session -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1693941&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1693941 ] Puzzled over list append bvehavior
Bugs item #1693941, was opened at 2007-04-03 17:44 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1693941&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.6 >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: elgordo (azgordo) Assigned to: Nobody/Anonymous (nobody) Summary: Puzzled over list append bvehavior Initial Comment: See attached IDLE session -- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-04-03 17:47 Message: Logged In: YES user_id=80475 Originator: NO Sorry, this isn't a bug. The append method modifies the list in-place and returns None. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1693941&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1647489 ] zero-length match confuses re.finditer()
Bugs item #1647489, was opened at 2007-01-29 17:35
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1647489&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: Regular Expressions
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jacques Frechet (jfrechet)
>Assigned to: Gustavo Niemeyer (niemeyer)
Summary: zero-length match confuses re.finditer()
Initial Comment:
Hi!
re.finditer() seems to incorrectly increment the current position immediately
after matching a zero-length substring. For example:
>>> [m.groups() for m in re.finditer(r'(^z*)|(\w+)', 'abc')]
[('', None), (None, 'bc')]
What happened to the 'a'? I expected this result:
[('', None), (None, 'abc')]
Perl agrees with me:
% perl -le 'print defined($1)?"\"$1\"":"undef",",",defined($2)?"\"$2\"":"undef"
while "abc" =~ /(z*)|(\w+)/g'
"",undef
undef,"abc"
"",undef
Similarly, if I remove the ^:
>>> [m.groups() for m in re.finditer(r'(z*)|(\w+)', 'abc')]
[('', None), ('', None), ('', None), ('', None)]
Now all of the letters have fallen through the cracks! I expected this result:
[('', None), (None, 'abc'), ('', None)]
Again, perl agrees:
% perl -le 'print defined($1)?"\"$1\"":"undef",",",defined($2)?"\"$2\"":"undef"
while "abc" =~ /(z*)|(\w+)/g'
"",undef
undef,"abc"
"",undef
If this bug has already been reported, I apologize -- I wasn't able to find it
here. I haven't looked at the code for the re module, but this seems like the
sort of bug that might have been accidentally introduced in order to try to
prevent the same zero-length match from being returned forever.
Thanks,
Jacques
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1647489&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1514428 ] NaN comparison in Decimal broken
Bugs item #1514428, was opened at 2006-06-29 11:19
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514428&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: 4
Private: No
Submitted By: Nick Maclaren (nmm)
Assigned to: Tim Peters (tim_one)
Summary: NaN comparison in Decimal broken
Initial Comment:
Methinks this is a bit off :-) True should be False.
Python 2.5b1 (trunk:47059, Jun 29 2006, 14:26:46)
[GCC 4.1.0 (SUSE Linux)] on linux2
>>> import decimal
>>> d = decimal.Decimal
>>> inf = d("inf")
>>> nan = d("nan")
>>> nan > inf
True
>>> nan < inf
False
>>> inf > nan
True
>>> inf < nan
False
b
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-05 21:05
Message:
Logged In: YES
user_id=80475
Originator: NO
The Decimal Arithmetic Specification says that NaN comparisons should
return NaN. The decimal module correctly implements this through the
compare() method:
>>> nan.compare(nan)
Decimal('NaN')
Since python's < and > operators return a boolean result, the standard is
silent on what should be done. The current implementation uses the __cmp__
method which can only return -1, 0, or 1, so there is not a direct way to
make both < and > both return False.
If you want to go beyond the standard and have both < and > return False
for all NaN comparisons, then the __cmp__ implementation would need to be
replaced with rich comparisons. I'm not sure that this is desirable. IMO,
that would be no better than the current arbitrary choice where all
comparisons involving NaN report self > other. If someone has an
application that would be harmed by the current implementation, then it
should almost certainly be use the standard compliant compare() method
instead of the boolean < and > operators.
Tim, what say you?
--
Comment By: CharlesMerriam (charlesmerriam)
Date: 2006-08-23 03:43
Message:
Logged In: YES
user_id=1581732
More specifically, any comparison with a NaN should equal
False, even inf, per IEEE 754. A good starting point to
convince oneself of this is http://en.wikipedia.org/wiki/NaN.
--
Comment By: Nick Maclaren (nmm)
Date: 2006-07-13 05:35
Message:
Logged In: YES
user_id=42444
It's still there in Beta 2.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514428&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1519638 ] Unmatched Group issue
Bugs item #1519638, was opened at 2006-07-09 13:34
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519638&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: Regular Expressions
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Bobby Xiao (nneonneo)
>Assigned to: Fredrik Lundh (effbot)
Summary: Unmatched Group issue
Initial Comment:
Using sre.sub[n], an "unmatched group" error can occur.
The test I used is this pattern:
sre.sub("foo(?:b(ar)|baz)","\\1","foobaz")
This will cause the following backtrace to occur:
Traceback (most recent call last):
File "", line 1, in ?
File "lib/python2.4/sre.py", line 142, in sub
return _compile(pattern, 0).sub(repl, string, count)
File "lib/python2.4/sre.py", line 260, in filter
return sre_parse.expand_template(template, match)
File "lib/python2.4/sre_parse.py", line 782, in expand_template
raise error, "unmatched group"
sre_constants.error: unmatched group
Python Version 2.4.3, Mac OS X (behaviour has been verified on
Windows 2.4.3 as well).
This behaviour, while by design, is unwanted because this type of
matching usually requests that a blank match be returned (i.e. the
example should return '')
The example that I was trying resembles the following:
sre.sub("User: (?:Registered User #(\d+)|Guest)","%USERID|\1%",data)
The intended behaviour is that the function returns "" when the user is
a guest and the user number if the user is a registered member.
However, when this function encounters a Guest, it raises an exception
and terminates, which is not what is wanted.
Perl and other regex engines behave as I have described, substituting
empty strings for unmatched groups. The code fix is relatively simple,
and would really help out for these types of things.
--
Comment By: Bobby Xiao (nneonneo)
Date: 2007-02-16 21:56
Message:
Logged In: YES
user_id=393491
Originator: YES
AFAIK the findall function works as desired in this respect: empty matches
will return empty strings.
--
Comment By: Matt Chaput (mchaput)
Date: 2007-02-15 13:35
Message:
Logged In: YES
user_id=1249840
Originator: NO
The current behavior also makes the "sub" function useless when you need
to backreference a group that might not capture, since you have no chance
to deal with the exception.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519638&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1684991 ] Explain __method__ lookup semantics for new-style classes
Bugs item #1684991, was opened at 2007-03-21 03:53 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1684991&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: Explain __method__ lookup semantics for new-style classes Initial Comment: __method__s (and next) are looked up on the type, not the instance. This isn't documented properly. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-04-03 19:21 Message: Logged In: YES user_id=80475 Originator: NO When writing docs, always cover the general case first and thoroughly. Keep the recommendations constructive, positive and useful (as opposed to wording like "this behavior should not be relied upon". A doc patch needs to add clarity -- if it doesn't, leave it out. -- Comment By: Steven Bethard (bediviere) Date: 2007-04-03 17:01 Message: Logged In: YES user_id=945502 Originator: NO This is not true for all __special__ methods, e.g. __enter__ and __exit__: >>> class C(object): ... pass ... >>> def enter(*args): ... print 'enter', args ... >>> def exit(*args): ... print 'exit', args ... >>> c = C() >>> c.__enter__ = enter >>> c.__exit__ = exit >>> with c: ... print 'hi' ... enter () hi exit (None, None, None) The documentation should say something like "When interpreting syntax that invokes a __special__ method, Python looks for the __special__ method on the instance's class. As an implementation detail, the lookup for some __special__ methods may also check the instance first, but this behavior should not be relied upon." This should probably go into the Reference Manual section 3.4: http://docs.python.org/ref/specialnames.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1684991&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1649098 ] non-standard: array[0]
Bugs item #1649098, was opened at 2007-01-31 13:25
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1649098&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: 6
Private: No
Submitted By: Johannes Abt (jabt)
Assigned to: Thomas Heller (theller)
Summary: non-standard: array[0]
Initial Comment:
in Modules/_ctypes/ctypes.h:
typedef struct {
[..]
ffi_type *atypes[0];
} ffi_info;
AFAIK, arrays must be of size > 0.
_Most_ compilers accepts this, but not all
(especially my HP-UX compiler).
Please change *atypes[0] to *atypes[1]!
Bye,
Johannes
--
Comment By: Thomas Heller (theller)
Date: 2007-02-28 15:43
Message:
Logged In: YES
user_id=11105
Originator: NO
I can, and probably will, change this in Modules/_ctypes/ctypes.h.
However, I'm afraid it will not help the OP too much because it seems he
cannot sucessfully compile the libffi sources with this HP-UX compiler
anyway because of at least *some* other problems.
I have the impression that libffi is GCC-specific, and unless someone
provides a complete patch for the HP-UX (or other) compilers it will
probably stay this way.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-02-25 17:24
Message:
Logged In: YES
user_id=33168
Originator: NO
Thomas, could you take a look?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1649098&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1594966 ] doctest simple usage recipe is misleading
Bugs item #1594966, was opened at 2006-11-12 03:31 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594966&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: 2 Private: No Submitted By: Ken Rimey (yemir) Assigned to: Tim Peters (tim_one) Summary: doctest simple usage recipe is misleading Initial Comment: "23.2.1 Simple Usage: Checking Examples in Docstrings" sets up a trap for the unsuspecting developer: http://docs.python.org/lib/doctest-simple-testmod.html That page recommends adding the following code to the end of a module using doctest: def _test(): import doctest doctest.testmod() if __name__ == "__main__": _test() The problem is that a reasonable person will figure that _test() has been defined for convenience in executing the tests from other Python code as follows: import M M._test() However, that executes the doctests found in __main__, not M! I think the recommended recipe should instead be as follows: if __name__ == "__main__": import doctest doctest.testmod() -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594966&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1563759 ] struct.unpack doens't support buffer protocol objects
Bugs item #1563759, was opened at 2006-09-22 17:17 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563759&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: 7 Private: No Submitted By: Adal Chiriliuc (adalx) Assigned to: Nobody/Anonymous (nobody) Summary: struct.unpack doens't support buffer protocol objects Initial Comment: If you pass an object which supports the buffer protocol to struct.unpack it will fail because it specifically checks for a string. You should use PyObject_AsReadBuffer instead. If this code is performance critical, you could add an unpack_buffer method or something like that. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-04-03 19:45 Message: Logged In: YES user_id=80475 Originator: NO This was due to Bob Ippolito's commit in revision 46184. -- Comment By: Adal Chiriliuc (adalx) Date: 2006-09-23 07:57 Message: Logged In: YES user_id=1067739 test_struct_run.py works in 2.4, throws exception in 2.5 -- Comment By: Adal Chiriliuc (adalx) Date: 2006-09-23 07:56 Message: Logged In: YES user_id=1067739 The actual code which broke used a Pointer extension class implemented in C++. I reproduced the problem using array.array. Using array in this way (without calling tostring) looks a bit weird. -- Comment By: Martin v. Löwis (loewis) Date: 2006-09-23 07:12 Message: Logged In: YES user_id=21627 Ah, so you say that was working previously? It's a bug, then. Can you provide a test case? -- Comment By: Adal Chiriliuc (adalx) Date: 2006-09-23 06:37 Message: Logged In: YES user_id=1067739 Well, because it broke previously working code and there is no warning in the documentation about that. In the mean-time, I've found out about pack_into and unpack_from which accept buffer like objects. Note that they are not documented in the struct module section, only mentioned in the "What's new" chapter. -- Comment By: Martin v. Löwis (loewis) Date: 2006-09-23 06:19 Message: Logged In: YES user_id=21627 Why is this a bug? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563759&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1684991 ] Explain __method__ lookup semantics for new-style classes
Bugs item #1684991, was opened at 2007-03-21 02:53 Message generated for change (Comment added) made by bediviere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1684991&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: Explain __method__ lookup semantics for new-style classes Initial Comment: __method__s (and next) are looked up on the type, not the instance. This isn't documented properly. -- Comment By: Steven Bethard (bediviere) Date: 2007-04-03 19:13 Message: Logged In: YES user_id=945502 Originator: NO Not sure exactly what you're proposing Raymond, but you could cut mine to "When interpreting syntax that invokes a __special__ method, Python looks for the __special__ method on the instance's class" if that's what you want. -- Comment By: Raymond Hettinger (rhettinger) Date: 2007-04-03 18:21 Message: Logged In: YES user_id=80475 Originator: NO When writing docs, always cover the general case first and thoroughly. Keep the recommendations constructive, positive and useful (as opposed to wording like "this behavior should not be relied upon". A doc patch needs to add clarity -- if it doesn't, leave it out. -- Comment By: Steven Bethard (bediviere) Date: 2007-04-03 16:01 Message: Logged In: YES user_id=945502 Originator: NO This is not true for all __special__ methods, e.g. __enter__ and __exit__: >>> class C(object): ... pass ... >>> def enter(*args): ... print 'enter', args ... >>> def exit(*args): ... print 'exit', args ... >>> c = C() >>> c.__enter__ = enter >>> c.__exit__ = exit >>> with c: ... print 'hi' ... enter () hi exit (None, None, None) The documentation should say something like "When interpreting syntax that invokes a __special__ method, Python looks for the __special__ method on the instance's class. As an implementation detail, the lookup for some __special__ methods may also check the instance first, but this behavior should not be relied upon." This should probably go into the Reference Manual section 3.4: http://docs.python.org/ref/specialnames.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1684991&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1690840 ] xmlrpclib methods submit call on __str__, __repr__
Bugs item #1690840, was opened at 2007-03-29 19:14
Message generated for change (Comment added) made by ghazel
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1690840&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Greg Hazel (ghazel)
Assigned to: Nobody/Anonymous (nobody)
Summary: xmlrpclib methods submit call on __str__, __repr__
Initial Comment:
Notice how trying to print a method causes it to submit the call:
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from xmlrpclib import ServerProxy
>>> s = ServerProxy("http://google.com";)
>>> print s.somecall
Traceback (most recent call last):
File "", line 1, in
File "c:\python25\lib\xmlrpclib.py", line 1147, in __call__
return self.__send(self.__name, args)
File "c:\python25\lib\xmlrpclib.py", line 1437, in __request
verbose=self.__verbose
File "c:\python25\lib\xmlrpclib.py", line 1191, in request
headers
xmlrpclib.ProtocolError: >> f = s.somecall
>>> locals()
{'f': Traceback (most recent call last):
File "", line 1, in
File "c:\python25\lib\xmlrpclib.py", line 1147, in __call__
return self.__send(self.__name, args)
File "c:\python25\lib\xmlrpclib.py", line 1437, in __request
verbose=self.__verbose
File "c:\python25\lib\xmlrpclib.py", line 1191, in request
headers
xmlrpclib.ProtocolError:
--
>Comment By: Greg Hazel (ghazel)
Date: 2007-04-04 06:45
Message:
Logged In: YES
user_id=731668
Originator: YES
This would be reasonable:
>>> from xmlrpclib import ServerProxy
>>> s = ServerProxy("http://google.com";)
>>> print s.somecall
Similarly:
>>> f = s.somecall
>>> locals()
{'f': , '__builtins__': , 's': , '__name__':
'__main__
', 'ServerProxy': , '__doc__':
None}
Bonus points for:
>
--
Comment By: Collin Winter (collinwinter)
Date: 2007-03-30 02:59
Message:
Logged In: YES
user_id=1344176
Originator: NO
What would you rather seem them print?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1690840&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
