[ python-Bugs-1235266 ] debug info file descriptor of tarfile is inconsistent
Bugs item #1235266, was opened at 2005-07-09 18:24 Message generated for change (Comment added) made by gustaebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235266&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.4 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: debug info file descriptor of tarfile is inconsistent Initial Comment: "7.19.1 TarFile Objects" says The messages are written to sys.stdout. but they are actually written to sys.stderr :: def _dbg(self, level, msg): """Write debugging output to sys.stderr. """ if level <= self.debug: print >> sys.stderr, msg There are 2 options: (a) change document from stdout to stderr. (b) rewrite the code to use stdout. Given this is debug messages and most other modules use stdout for debug printing(gc is one of the few exceptions?), I'm +1 on (b). [*] http://docs.python.org/lib/tarfile-objects.html -- Comment By: Lars Gustäbel (gustaebel) Date: 2005-07-10 10:00 Message: Logged In: YES user_id=642936 This is a documentation error. Debug messages must go to stderr because that's what stderr is for. Think of a script that writes a tar archive to stdout for use in a unix shell pipeline. If debug messages went to stdout, too, it would produce unusable output, because archive data and debug messages would be mixed. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-09 19:04 Message: Logged In: YES user_id=1188172 The documentation seems to be borrowed from zipfile, where the statement is true: debug info is written to stdout. I'm in favour of changing the docs to stderr for tarfile. What about zipfile? Should we print debug info to stderr there, too? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235266&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1235569 ] Inconsistent singleton constructor messages
Bugs item #1235569, was opened at 2005-07-10 05:18 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=1235569&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Pavel Pergamenshchik (ppergame) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent singleton constructor messages Initial Comment: Inconsistent TypeError strings: >>> types.NoneType() Traceback (most recent call last): File "", line 1, in ? TypeError: cannot create 'NoneType' instances >>> types.EllipsisType() Traceback (most recent call last): File "", line 1, in ? TypeError: cannot create 'ellipsis' instances -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235569&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1235569 ] Inconsistent singleton constructor messages
Bugs item #1235569, was opened at 2005-07-10 14:18 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235569&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Pavel Pergamenshchik (ppergame) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent singleton constructor messages Initial Comment: Inconsistent TypeError strings: >>> types.NoneType() Traceback (most recent call last): File "", line 1, in ? TypeError: cannot create 'NoneType' instances >>> types.EllipsisType() Traceback (most recent call last): File "", line 1, in ? TypeError: cannot create 'ellipsis' instances -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-10 15:28 Message: Logged In: YES user_id=1188172 Where's your problem? If this doesn't cause any misbehaviour, I recommend closing this as Won't Fix. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235569&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1235266 ] debug info file descriptor of tarfile is inconsistent
Bugs item #1235266, was opened at 2005-07-10 01:24 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235266&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.4 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: debug info file descriptor of tarfile is inconsistent Initial Comment: "7.19.1 TarFile Objects" says The messages are written to sys.stdout. but they are actually written to sys.stderr :: def _dbg(self, level, msg): """Write debugging output to sys.stderr. """ if level <= self.debug: print >> sys.stderr, msg There are 2 options: (a) change document from stdout to stderr. (b) rewrite the code to use stdout. Given this is debug messages and most other modules use stdout for debug printing(gc is one of the few exceptions?), I'm +1 on (b). [*] http://docs.python.org/lib/tarfile-objects.html -- >Comment By: George Yoshida (quiver) Date: 2005-07-11 01:26 Message: Logged In: YES user_id=671362 OK. I tested some GNU compression/decompression tools and comfirmed that they write debugging messages (displayed in verbose mode(-v)) to stderr. Now I'm leaning toward Reinhold's idea. > What about zipfile? > Should we print debug info to stderr there, too? Maybe yes. I'd be happy to volunteer for that patch. -- Comment By: Lars Gustäbel (gustaebel) Date: 2005-07-10 17:00 Message: Logged In: YES user_id=642936 This is a documentation error. Debug messages must go to stderr because that's what stderr is for. Think of a script that writes a tar archive to stdout for use in a unix shell pipeline. If debug messages went to stdout, too, it would produce unusable output, because archive data and debug messages would be mixed. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-10 02:04 Message: Logged In: YES user_id=1188172 The documentation seems to be borrowed from zipfile, where the statement is true: debug info is written to stdout. I'm in favour of changing the docs to stderr for tarfile. What about zipfile? Should we print debug info to stderr there, too? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235266&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1235646 ] codecs.StreamRecoder.next doesn't encode
Bugs item #1235646, was opened at 2005-07-10 18:55 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=1235646&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.4 Status: Open Resolution: None Priority: 5 Submitted By: Sebastian Wangnick (wangnick) Assigned to: M.-A. Lemburg (lemburg) Summary: codecs.StreamRecoder.next doesn't encode Initial Comment: Codecs.StreamRecode.next does't encode the data it gets from self.reader.next. This breaks the "for line in codecs.EncodedFile(...)" idiom. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235646&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1003935 ] xrange overflows
Bugs item #1003935, was opened at 2004-08-05 09:16 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003935&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Hallvard B Furuseth (hfuru) >Assigned to: Nobody/Anonymous (nobody) Summary: xrange overflows Initial Comment: These restrictions are undocumented both in the xrange doc string and in the reference manual (Info node 'XRange Type'): >>> xrange(maxint, maxint + 10) Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to int >>> xrange(-100, maxint) Traceback (most recent call last): File "", line 1, in ? OverflowError: xrange() result has too many items I hope the overflows below are bugs and not features. It works if 3/-3 is replaced with 1/-1: >>> xrange(0, maxint, 3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition >>> xrange(0, -maxint, -3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition Python installation: Python 2.3.3 (#1, May 25 2004, 20:22:36) [GCC 3.2.3] on sunos5 Type "help", "copyright", "credits" or "license" formore information. >>> from sys import maxint >>> "%x" % maxint '7fff' -- >Comment By: Tim Peters (tim_one) Date: 2005-07-10 17:19 Message: Logged In: YES user_id=31435 Unassigned myself, since I don't plan to do anything else here. -- Comment By: Connelly (connelly) Date: 2004-12-06 02:04 Message: Logged In: YES user_id=1039782 Yes, I run into this bug all the time. For example, I may want to generate all strings of length n: BINARY_CHARSET = ''.join([chr(i) for i in range(256)]) def all_strs(n, charset=BINARY_CHARSET): m = len(charset) for i in xrange(m**n): yield ''.join([charset[i//m**j%m] for j in range(n)]) This is correct algorithmically, but fails due to the buggy Python xrange() function. So I end up writing my own irange () function. Other cases where I've run into this problem: Sieving for primes starting at a given large prime, checking for integer solutions to an equation starting with a large integer, and searching very large integer sets. itertools.count and itertools.repeat are similarly annoying. Often I want to search the list of all positive integers starting with 1, and have to use an awkward while loop to do this, or write my own replacement for itertools.count. There should be little performance hit for apps which use xrange(n), where n fits in the system's integer size. xrange () can just return an iterator which returns system ints, and the only performance penalty is an extra if statement in the call to xrange (and there is no performance penalty in the iterator's next() method). Finally, this move appears consistent with Python's values, ie simplicity, long ints supported with no extra effort, avoid gotchas for newbies, no special cases, etc. -- Comment By: Hallvard B Furuseth (hfuru) Date: 2004-08-08 14:09 Message: Logged In: YES user_id=726647 Here is why repr() is relevant - though the error message was certainly weird. With the latest CVS version: >>> xrange(maxint-1, maxint, 2) xrange(2147483646, -2147483648, 2) Which is why I suggested to return last+step/abs(step) as the 2nd argument. -- Comment By: Tim Peters (tim_one) Date: 2004-08-08 03:20 Message: Logged In: YES user_id=31435 Changed range_new() to stop using PyRange_New(). This fixes a variety of bogus errors. Documented that xrange() is intended to be simple and fast, and that CPython restricts its arguments, and length of its result sequence, to native C longs. Added some tests that failed before the patch, and repaired a test that relied on a bogus OverflowError getting raised. Doc/lib/libfuncs.tex; new revision: 1.171 Lib/test/test_xrange.py; new revision: 1.2 Objects/rangeobject.c; new revision: 2.53 -- Comment By: Tim Peters (tim_one) Date: 2004-08-06 01:10 Message: Logged In: YES user_id=31435 It looks like there are two bugs here. One is that the "integer addition" detail doesn't make sense, since the user isn't doing any integer addition here (sorry, no, repr() is irrelevant to this). Second, it shouldn't be complaining in the last two cases at alll. If the numbers truly were out of range, th
[ python-Bugs-1185883 ] PyObject_Realloc bug in obmalloc.c
Bugs item #1185883, was opened at 2005-04-19 08:07 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1185883&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.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Kristján Valur (krisvale) Assigned to: Tim Peters (tim_one) Summary: PyObject_Realloc bug in obmalloc.c Initial Comment: obmalloc.c:835 If the previous block was not handled by obmalloc, and the realloc is for growing the block, this memcpy may cross a page boundary and cause a segmentation fault. This scenario can happen if a previous allocation failed to successfully allocate from the obmalloc pools, due to memory starvation or other reasons, but was successfully allocated by the c runtime. The solution is to query the actual size of the allocated block, and copy only so much memory. Most modern platforms provide size query functions complementing the malloc()/free() calls. on Windows, this is the _msize () function. -- >Comment By: Tim Peters (tim_one) Date: 2005-07-10 18:33 Message: Logged In: YES user_id=31435 Repaired, in Misc/NEWS 1.1312 Objects/obmalloc.c 2.54 Should be backported to 2.4 maint. -- Comment By: Michael Hudson (mwh) Date: 2005-05-27 05:35 Message: Logged In: YES user_id=6656 Ping! -- Comment By: Tim Peters (tim_one) Date: 2005-04-19 11:34 Message: Logged In: YES user_id=31435 krisvale: Thank you for the very clear explanation. Even I understand this now . We won't use _msize here -- Python has to run under dozens of compilers and C libraries, and it's saner to give up on this "optimization" completely than to introduce a rat's nest of #ifdefs here. IOW, I expect the entire "if (nbytes <= SMALL_REQUEST_THRESHOLD)" block will go away, so that the platform realloc() gets called in every case obmalloc doesn't control the incoming block. BTW, note that there's no plan to do another release in the Python 2.3 line. -- Comment By: Kristján Valur (krisvale) Date: 2005-04-19 11:22 Message: Logged In: YES user_id=1262199 The platform is windows 2000/2003 server, single threaded C runtime. I have only had the chance to do postmortem debugging on this but it would appear to be as you describe: The following page is not mapped in. Windows doesn´t use the setbrk() method of heap management and doesn´t automatically move the break. Rather they (the multiple heaps) requests pages as required. A malloc may have succeeded from a different page and copying to much from the old block close to the boundary caused an exception _at_ the page boundary. Fyi, old block was 68 bytes at 0x6d85efb8. This block ends at -effc. The new size requested was 108 bytes. Reading 108 bytes from this address caused an exception at address 0x6d85f000. As you know, reading past a malloc block results in undefined behaviour and sometimes this can mean a crash. I have patched python locally to use MIN(nbytes, _msize(p)) in stead and we are about to run the modified version on our server cluster. Nodes were dying quite regularly because of this. I'll let you know if this changes anyting in that aspect. Btw, I work for ccp games, and we are running the MMORPG eve online (www.eveonline.com) -- Comment By: Tim Peters (tim_one) Date: 2005-04-19 11:00 Message: Logged In: YES user_id=31435 mwh: Umm ... I don't understand what the claim is. For example, what HW does Python run on where memcpy segfaults just because the address range crosses a page boundary? If that's what's happening, sounds more like a bug in the platform memcpy. I can memcpy blocks spanning thousands of pages on my box -- and so can you . krisvale: which OS and which C are you using? It is true that this code may try to access a bit of memory that wasn't allocated. If that's at the end of the address space, then I could see a segfault happening. If it is, I doubt there's any portable way to fix it short of PyObject_Realloc never trying to take over small blocks it didn't control to begin with. Then the platform realloc() will segfault instead . -- Comment By: Kristján Valur (krisvale) Date: 2005-04-19 10:39 Message: Logged In: YES user_id=1262199 I can only say that I´ve been seeing this happeing with our software. Admittedly it's because we are eating up all me
[ python-Bugs-1185883 ] PyObject_Realloc bug in obmalloc.c
Bugs item #1185883, was opened at 2005-04-19 07:07 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1185883&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.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Kristján Valur (krisvale) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: PyObject_Realloc bug in obmalloc.c Initial Comment: obmalloc.c:835 If the previous block was not handled by obmalloc, and the realloc is for growing the block, this memcpy may cross a page boundary and cause a segmentation fault. This scenario can happen if a previous allocation failed to successfully allocate from the obmalloc pools, due to memory starvation or other reasons, but was successfully allocated by the c runtime. The solution is to query the actual size of the allocated block, and copy only so much memory. Most modern platforms provide size query functions complementing the malloc()/free() calls. on Windows, this is the _msize () function. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-10 18:07 Message: Logged In: YES user_id=80475 Reinhold, would you like to do the backport? -- Comment By: Tim Peters (tim_one) Date: 2005-07-10 17:33 Message: Logged In: YES user_id=31435 Repaired, in Misc/NEWS 1.1312 Objects/obmalloc.c 2.54 Should be backported to 2.4 maint. -- Comment By: Michael Hudson (mwh) Date: 2005-05-27 04:35 Message: Logged In: YES user_id=6656 Ping! -- Comment By: Tim Peters (tim_one) Date: 2005-04-19 10:34 Message: Logged In: YES user_id=31435 krisvale: Thank you for the very clear explanation. Even I understand this now . We won't use _msize here -- Python has to run under dozens of compilers and C libraries, and it's saner to give up on this "optimization" completely than to introduce a rat's nest of #ifdefs here. IOW, I expect the entire "if (nbytes <= SMALL_REQUEST_THRESHOLD)" block will go away, so that the platform realloc() gets called in every case obmalloc doesn't control the incoming block. BTW, note that there's no plan to do another release in the Python 2.3 line. -- Comment By: Kristján Valur (krisvale) Date: 2005-04-19 10:22 Message: Logged In: YES user_id=1262199 The platform is windows 2000/2003 server, single threaded C runtime. I have only had the chance to do postmortem debugging on this but it would appear to be as you describe: The following page is not mapped in. Windows doesn´t use the setbrk() method of heap management and doesn´t automatically move the break. Rather they (the multiple heaps) requests pages as required. A malloc may have succeeded from a different page and copying to much from the old block close to the boundary caused an exception _at_ the page boundary. Fyi, old block was 68 bytes at 0x6d85efb8. This block ends at -effc. The new size requested was 108 bytes. Reading 108 bytes from this address caused an exception at address 0x6d85f000. As you know, reading past a malloc block results in undefined behaviour and sometimes this can mean a crash. I have patched python locally to use MIN(nbytes, _msize(p)) in stead and we are about to run the modified version on our server cluster. Nodes were dying quite regularly because of this. I'll let you know if this changes anyting in that aspect. Btw, I work for ccp games, and we are running the MMORPG eve online (www.eveonline.com) -- Comment By: Tim Peters (tim_one) Date: 2005-04-19 10:00 Message: Logged In: YES user_id=31435 mwh: Umm ... I don't understand what the claim is. For example, what HW does Python run on where memcpy segfaults just because the address range crosses a page boundary? If that's what's happening, sounds more like a bug in the platform memcpy. I can memcpy blocks spanning thousands of pages on my box -- and so can you . krisvale: which OS and which C are you using? It is true that this code may try to access a bit of memory that wasn't allocated. If that's at the end of the address space, then I could see a segfault happening. If it is, I doubt there's any portable way to fix it short of PyObject_Realloc never trying to take over small blocks it didn't control to begin with. Then the platform realloc() will segfault instead . -
[ python-Feature Requests-1003935 ] xrange overflows
Feature Requests item #1003935, was opened at 2004-08-05 08:16 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1003935&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 Submitted By: Hallvard B Furuseth (hfuru) >Assigned to: Raymond Hettinger (rhettinger) Summary: xrange overflows Initial Comment: These restrictions are undocumented both in the xrange doc string and in the reference manual (Info node 'XRange Type'): >>> xrange(maxint, maxint + 10) Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to int >>> xrange(-100, maxint) Traceback (most recent call last): File "", line 1, in ? OverflowError: xrange() result has too many items I hope the overflows below are bugs and not features. It works if 3/-3 is replaced with 1/-1: >>> xrange(0, maxint, 3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition >>> xrange(0, -maxint, -3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition Python installation: Python 2.3.3 (#1, May 25 2004, 20:22:36) [GCC 3.2.3] on sunos5 Type "help", "copyright", "credits" or "license" formore information. >>> from sys import maxint >>> "%x" % maxint '7fff' -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-10 18:11 Message: Logged In: YES user_id=80475 Will look at it to see if there is something simple that can be done. These were design decisions -- xrange() and count() are supposed to be simple and fast -- with other tools being preferred if you are pushing beyond the limit of normal use cases. IOW, it is not worth crippling their performance just because someone has discovered cute ways of using sys.maxint. -- Comment By: Tim Peters (tim_one) Date: 2005-07-10 16:19 Message: Logged In: YES user_id=31435 Unassigned myself, since I don't plan to do anything else here. -- Comment By: Connelly (connelly) Date: 2004-12-06 02:04 Message: Logged In: YES user_id=1039782 Yes, I run into this bug all the time. For example, I may want to generate all strings of length n: BINARY_CHARSET = ''.join([chr(i) for i in range(256)]) def all_strs(n, charset=BINARY_CHARSET): m = len(charset) for i in xrange(m**n): yield ''.join([charset[i//m**j%m] for j in range(n)]) This is correct algorithmically, but fails due to the buggy Python xrange() function. So I end up writing my own irange () function. Other cases where I've run into this problem: Sieving for primes starting at a given large prime, checking for integer solutions to an equation starting with a large integer, and searching very large integer sets. itertools.count and itertools.repeat are similarly annoying. Often I want to search the list of all positive integers starting with 1, and have to use an awkward while loop to do this, or write my own replacement for itertools.count. There should be little performance hit for apps which use xrange(n), where n fits in the system's integer size. xrange () can just return an iterator which returns system ints, and the only performance penalty is an extra if statement in the call to xrange (and there is no performance penalty in the iterator's next() method). Finally, this move appears consistent with Python's values, ie simplicity, long ints supported with no extra effort, avoid gotchas for newbies, no special cases, etc. -- Comment By: Hallvard B Furuseth (hfuru) Date: 2004-08-08 13:09 Message: Logged In: YES user_id=726647 Here is why repr() is relevant - though the error message was certainly weird. With the latest CVS version: >>> xrange(maxint-1, maxint, 2) xrange(2147483646, -2147483648, 2) Which is why I suggested to return last+step/abs(step) as the 2nd argument. -- Comment By: Tim Peters (tim_one) Date: 2004-08-08 02:20 Message: Logged In: YES user_id=31435 Changed range_new() to stop using PyRange_New(). This fixes a variety of bogus errors. Documented that xrange() is intended to be simple and fast, and that CPython restricts its arguments, and length of its result sequence, to native C longs. Added some tests that failed before the patch, and repaired a test that relied on a bogus OverflowError getting raised. Doc/lib/libfuncs.tex; new revision: 1.171 Lib
[ python-Bugs-1219840 ] Need locale arg to strftime()
Bugs item #1219840, was opened at 2005-06-13 10:32 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1219840&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Wilfredo Sanchez (wsanchez) Assigned to: Brett Cannon (bcannon) Summary: Need locale arg to strftime() Initial Comment: strftime()'s behavior is dependant on your current locale. Sometimes this is undesireable, such as when parsing HTTP dates (RFC 2068, 3.3.1), where on is expected to create and parse dates using English month and week names. A similar problem exists with the lower() string method. In either case locale magic isn't always desirable, and it would be useful to add a locale argument to specify which locale to use. -- >Comment By: Brett Cannon (bcannon) Date: 2005-07-10 20:10 Message: Logged In: YES user_id=357491 Since no one can seem to refute my logic I am closing this as invalid. -- Comment By: Brett Cannon (bcannon) Date: 2005-06-14 19:14 Message: Logged In: YES user_id=357491 There is an issue with this idea. strftime() is just a wrapper around the ISO C library function. We have no direct control over the locale handling. This means that the locale used by strftime() is dictated by the locale that the ISO C libraries think you have. Best thing to do is to temporarily change the locale to what you need, use strftime(), and then set the locale back. PEP 342 would be nice for this. =) At best this is what strftime() would have to do behind the scenes for you. And the extra overhead is not totally desirable. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-14 01:59 Message: Logged In: YES user_id=80475 Brett, do you want to take this one? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1219840&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1190012 ] ``from sys import stdin, `` doesn't raise a SyntaxError
Bugs item #1190012, was opened at 2005-04-25 23:11 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190012&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: AST >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: ``from sys import stdin,`` doesn't raise a SyntaxError Initial Comment: Python 2.4 raises a SyntaxError: "trailing comma not allowed without surrounding parentheses". Detected by test_compile. -- >Comment By: Brett Cannon (bcannon) Date: 2005-07-10 20:31 Message: Logged In: YES user_id=357491 Patch #1194895 was accepted and checked in; closing as fixed. -- Comment By: logistix (logistix) Date: 2005-05-04 16:14 Message: Logged In: YES user_id=699438 Patch 1194895 fixes this. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190012&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1190011 ] [AST] distinct code objects not created
Bugs item #1190011, was opened at 2005-04-25 23:10 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190011&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: AST >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Brett Cannon (bcannon) Summary: [AST] distinct code objects not created Initial Comment: >> def f(): return ((lambda x=1: x), (lambda x=2: x)) >> f1, f2 = f() >> id(f1.func_code) != id(f2.func_code) The above does not hold true. It should according to test_compile (reported in HEAD as bug #1048870). -- >Comment By: Brett Cannon (bcannon) Date: 2005-07-10 20:37 Message: Logged In: YES user_id=357491 Looks fine to me. Checked in as rev. 1.1.2.3 . test_compile now passes! -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 05:11 Message: Logged In: YES user_id=1038590 The same fix mwh used for HEAD appears to work for the AST branch, too (it's just in a different source file). Patch attached, and kicking in Brett's direction for review. -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 04:02 Message: Logged In: YES user_id=1038590 For the code above, Python 2.4.1 actually generates a single code object (that is, the comparison returns False). Looking closer at 1048870, this is expected, as the two lambdas are created on the same line. I'll look into this on the AST branch - I suspect the culprit may be our problems with getting the line numbering right. (FWIW, I worked out the UnboundLocal problem, and followed it up in the relevant bug, 1186353) -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 01:26 Message: Logged In: YES user_id=1038590 This seems to be the least of lambda's problems. A number of regression tests currently fail with UnboundLocalErrors, after an argument of the form "lambda (x, y): x" is passed to a function for invocation. Assigning to myself, since I'm about to take a look at the current misbehaviour of lambdas (they must be simpler than genexps, right?) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190011&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1186353 ] [AST] automatic unpacking of arguments broken
Bugs item #1186353, was opened at 2005-04-19 16:37 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1186353&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: AST Status: Open >Resolution: Accepted Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Brett Cannon (bcannon) Summary: [AST] automatic unpacking of arguments broken Initial Comment: The code ``(lambda (x, y): x)((3, 5))`` fails because the passed-in tuple is not unpacked into the arguments. -- >Comment By: Brett Cannon (bcannon) Date: 2005-07-10 20:44 Message: Logged In: YES user_id=357491 Applied in rev. 1.1.2.109 . Closed as accepted. -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 03:34 Message: Logged In: YES user_id=1038590 After looking in all the wrong places, it turned out to be something simple in the compiler. I factored out the relevant code from the function compilation, so that lambda compilation can use it too. Assigning to Brett for review. -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 02:41 Message: Logged In: YES user_id=1038590 Investigating lambda behaviour, as per comment on 1190011 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1186353&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1186353 ] [AST] automatic unpacking of arguments broken
Bugs item #1186353, was opened at 2005-04-19 16:37 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1186353&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: AST >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Brett Cannon (bcannon) Summary: [AST] automatic unpacking of arguments broken Initial Comment: The code ``(lambda (x, y): x)((3, 5))`` fails because the passed-in tuple is not unpacked into the arguments. -- Comment By: Brett Cannon (bcannon) Date: 2005-07-10 20:44 Message: Logged In: YES user_id=357491 Applied in rev. 1.1.2.109 . Closed as accepted. -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 03:34 Message: Logged In: YES user_id=1038590 After looking in all the wrong places, it turned out to be something simple in the compiler. I factored out the relevant code from the function compilation, so that lambda compilation can use it too. Assigning to Brett for review. -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 02:41 Message: Logged In: YES user_id=1038590 Investigating lambda behaviour, as per comment on 1190011 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1186353&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1186195 ] [AST] genexps get scoping wrong
Bugs item #1186195, was opened at 2005-04-19 12:02 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1186195&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: AST >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Brett Cannon (bcannon) Summary: [AST] genexps get scoping wrong Initial Comment: test_genexps is failing because it is unable to find a global defined in a genexp that is returned. Here is the problem simplified: def f(n): return (i for i in xrange(n)) list(f(10)) Leads to ``SystemError: no locals when loading 'xrange'``. Comparing Python 2.4 bytecode: 1 0 LOAD_CONST 1 ( at 0x3931e0, file "", line 1>) 3 MAKE_FUNCTION0 6 LOAD_GLOBAL 0 (xrange) 9 LOAD_FAST0 (n) 12 CALL_FUNCTION1 15 GET_ITER 16 CALL_FUNCTION1 19 RETURN_VALUE 20 LOAD_CONST 0 (None) 23 RETURN_VALUE to AST bytecode: 1 0 LOAD_CLOSURE 0 (n) 3 BUILD_TUPLE 1 6 LOAD_CONST 1 ( at 0x5212e8, file "", line 1>) 9 MAKE_CLOSURE 0 12 LOAD_NAME0 (xrange) 15 LOAD_DEREF 0 (n) 18 CALL_FUNCTION1 21 GET_ITER 22 CALL_FUNCTION1 25 RETURN_VALUE 26 LOAD_CONST 0 (None) 29 RETURN_VALUE makes it obvious something is off (no peepholer; turned it off in my build of 2.4). Looks like extraneous work is being done in making a closure. Seems like it will still work, though. Plus the usage of LOAD_NAME is wrong in the AST; LOAD_NAME gets an object from the local namespace based on its name instead of offset. -- >Comment By: Brett Cannon (bcannon) Date: 2005-07-10 20:53 Message: Logged In: YES user_id=357491 rev. 2.10.8.34 has the patch. Thanks, Nick. -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 00:49 Message: Logged In: YES user_id=1038590 Scratch that comment about applying a similar methodology to the compiler stage - the need to correctly structure the generate bytecode makes things a lot uglier, so the simple trick I used to get the symbol table scoping right doesn't apply (the outer loops need to do things before *and after* the inner loops in the compiler stage). -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 00:33 Message: Logged In: YES user_id=1038590 Tag, you're it :) -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 00:32 Message: Logged In: YES user_id=1038590 Patch attached that means test_genexps mostly passes for me. The two which still fail are actually problems with assignment statements (the AST branch does not yet intercept attempts to assign to genexps and produce a nice error message). I'm also much happier with the implementation technique I used this time around - something similar should work for the compiler implementation, hopefully permitting it to be simplified (I'm going to look at that now, and will post a separate patch if it works out). -- Comment By: Brett Cannon (bcannon) Date: 2005-04-20 23:13 Message: Logged In: YES user_id=357491 OK, so basically what I figured out earlier today. I noticed that both genexps in 2.4 and the AST branch generated the same bytecode, so the only difference was how it was handling passing in arguments to the generator for its initial creation. I figured there was some jiggering in the compiler to note that the scoping in the genexp should not affect how variables were handled for its arguments. And as you said, the AST branch just doesn't take this into consideration as it should. I will see if I get to it, but I doubt I will (leaving town Friday for the weekend). I think this has justified fleshing out Python/compile.txt with a more thorough discussion of how the symbol table is generated. If you have any specific points you think should go in there, Nick (or anyone for that matter), please email them to me. Even explaining how the whole thing works would be a help. =)
[ python-Bugs-1191458 ] [AST] Failing tests
Bugs item #1191458, was opened at 2005-04-27 20:30 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191458&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: AST Status: Open Resolution: None Priority: 9 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: [AST] Failing tests Initial Comment: This tracker item is to be used to keep track of what tests are currently failing on the AST branch. This is somewhat important sinced there are so many failures it can be hard to detect if a change fixed what it was supposed to or actually managed to break more code. When posting follow-ups of fixed tests, please re-list the currently failing tests so as to make it simple to reference the current state of things. So, the current offenders are (from a straight ``regrtest.py`` run on my OS X box, which always has test__locale fail so I removed it):: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_itertools test_new test_peepholer test_scope test_socket test_sort test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings test_zipfile -- >Comment By: Brett Cannon (bcannon) Date: 2005-07-10 21:13 Message: Logged In: YES user_id=357491 After applying all patches associated with all open bugs, the failing tests from ``./python.exe Lib/test/regrtest.py`` are: 14 tests failed: test_cookielib test_dis test_future test_genexps test_inspect test_new test_peepholer test_scope test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 04:40 Message: Logged In: YES user_id=1038590 Fixing #1186353 (lambda argument unpacking) fixes test_sort and test_itertools: 17 tests failed: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_new test_ossaudiodev test_peepholer test_scope test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 01:33 Message: Logged In: YES user_id=1038590 Bumped bug priority to 9 so it stays on top of the SF tracker. Also, we can't merge the AST branch until this bug is closed, so it is fairly important to close out these issues :) Running "./python Lib/test/regrtest.py -uall" Suse Linux 9.1: 20 tests failed: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_itertools test_new test_ossaudiodev test_peepholer test_scope test_sort test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings test_zipfile WIth the patch for 1186195 (genexp scoping) applied I get: 19 tests failed: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_itertools test_new test_ossaudiodev test_peepholer test_scope test_sort test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings The remaining test_genexps failures are due to assignment statements not checking for genexps as illegal targets. Running test_zipfile in verbose mode indicated genexp problems, so it makes sense that fixing the scoping eliminated those failures. I'm going to look at lambdas next, since they seem to be the culprits with respect to a few different test failures. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191458&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1191458 ] [AST] Failing tests
Bugs item #1191458, was opened at 2005-04-27 20:30 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191458&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: AST Status: Open Resolution: None Priority: 9 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: [AST] Failing tests Initial Comment: This tracker item is to be used to keep track of what tests are currently failing on the AST branch. This is somewhat important sinced there are so many failures it can be hard to detect if a change fixed what it was supposed to or actually managed to break more code. When posting follow-ups of fixed tests, please re-list the currently failing tests so as to make it simple to reference the current state of things. So, the current offenders are (from a straight ``regrtest.py`` run on my OS X box, which always has test__locale fail so I removed it):: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_itertools test_new test_peepholer test_scope test_socket test_sort test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings test_zipfile -- >Comment By: Brett Cannon (bcannon) Date: 2005-07-10 21:15 Message: Logged In: YES user_id=357491 Scratch the "all open bugs" comment; didn't get to bug #1195576. -- Comment By: Brett Cannon (bcannon) Date: 2005-07-10 21:13 Message: Logged In: YES user_id=357491 After applying all patches associated with all open bugs, the failing tests from ``./python.exe Lib/test/regrtest.py`` are: 14 tests failed: test_cookielib test_dis test_future test_genexps test_inspect test_new test_peepholer test_scope test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 04:40 Message: Logged In: YES user_id=1038590 Fixing #1186353 (lambda argument unpacking) fixes test_sort and test_itertools: 17 tests failed: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_new test_ossaudiodev test_peepholer test_scope test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 01:33 Message: Logged In: YES user_id=1038590 Bumped bug priority to 9 so it stays on top of the SF tracker. Also, we can't merge the AST branch until this bug is closed, so it is fairly important to close out these issues :) Running "./python Lib/test/regrtest.py -uall" Suse Linux 9.1: 20 tests failed: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_itertools test_new test_ossaudiodev test_peepholer test_scope test_sort test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings test_zipfile WIth the patch for 1186195 (genexp scoping) applied I get: 19 tests failed: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_itertools test_new test_ossaudiodev test_peepholer test_scope test_sort test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings The remaining test_genexps failures are due to assignment statements not checking for genexps as illegal targets. Running test_zipfile in verbose mode indicated genexp problems, so it makes sense that fixing the scoping eliminated those failures. I'm going to look at lambdas next, since they seem to be the culprits with respect to a few different test failures. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191458&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1185883 ] PyObject_Realloc bug in obmalloc.c
Bugs item #1185883, was opened at 2005-04-19 14:07 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1185883&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.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Kristján Valur (krisvale) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: PyObject_Realloc bug in obmalloc.c Initial Comment: obmalloc.c:835 If the previous block was not handled by obmalloc, and the realloc is for growing the block, this memcpy may cross a page boundary and cause a segmentation fault. This scenario can happen if a previous allocation failed to successfully allocate from the obmalloc pools, due to memory starvation or other reasons, but was successfully allocated by the c runtime. The solution is to query the actual size of the allocated block, and copy only so much memory. Most modern platforms provide size query functions complementing the malloc()/free() calls. on Windows, this is the _msize () function. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-11 08:03 Message: Logged In: YES user_id=1188172 Done. Misc/NEWS r1.1193.2.61, Objects/obmalloc.c r2.53.4.1. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-11 01:07 Message: Logged In: YES user_id=80475 Reinhold, would you like to do the backport? -- Comment By: Tim Peters (tim_one) Date: 2005-07-11 00:33 Message: Logged In: YES user_id=31435 Repaired, in Misc/NEWS 1.1312 Objects/obmalloc.c 2.54 Should be backported to 2.4 maint. -- Comment By: Michael Hudson (mwh) Date: 2005-05-27 11:35 Message: Logged In: YES user_id=6656 Ping! -- Comment By: Tim Peters (tim_one) Date: 2005-04-19 17:34 Message: Logged In: YES user_id=31435 krisvale: Thank you for the very clear explanation. Even I understand this now . We won't use _msize here -- Python has to run under dozens of compilers and C libraries, and it's saner to give up on this "optimization" completely than to introduce a rat's nest of #ifdefs here. IOW, I expect the entire "if (nbytes <= SMALL_REQUEST_THRESHOLD)" block will go away, so that the platform realloc() gets called in every case obmalloc doesn't control the incoming block. BTW, note that there's no plan to do another release in the Python 2.3 line. -- Comment By: Kristján Valur (krisvale) Date: 2005-04-19 17:22 Message: Logged In: YES user_id=1262199 The platform is windows 2000/2003 server, single threaded C runtime. I have only had the chance to do postmortem debugging on this but it would appear to be as you describe: The following page is not mapped in. Windows doesn´t use the setbrk() method of heap management and doesn´t automatically move the break. Rather they (the multiple heaps) requests pages as required. A malloc may have succeeded from a different page and copying to much from the old block close to the boundary caused an exception _at_ the page boundary. Fyi, old block was 68 bytes at 0x6d85efb8. This block ends at -effc. The new size requested was 108 bytes. Reading 108 bytes from this address caused an exception at address 0x6d85f000. As you know, reading past a malloc block results in undefined behaviour and sometimes this can mean a crash. I have patched python locally to use MIN(nbytes, _msize(p)) in stead and we are about to run the modified version on our server cluster. Nodes were dying quite regularly because of this. I'll let you know if this changes anyting in that aspect. Btw, I work for ccp games, and we are running the MMORPG eve online (www.eveonline.com) -- Comment By: Tim Peters (tim_one) Date: 2005-04-19 17:00 Message: Logged In: YES user_id=31435 mwh: Umm ... I don't understand what the claim is. For example, what HW does Python run on where memcpy segfaults just because the address range crosses a page boundary? If that's what's happening, sounds more like a bug in the platform memcpy. I can memcpy blocks spanning thousands of pages on my box -- and so can you . krisvale: which OS and which C are you using? It is true that this code may try to access a bit of memory that wasn't allocated. If that's at the end of the address space, then I could see a segfault happening. If it is, I doubt ther
[ python-Bugs-1235266 ] debug info file descriptor of tarfile is inconsistent
Bugs item #1235266, was opened at 2005-07-09 18:24 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235266&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.4 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) >Assigned to: Raymond Hettinger (rhettinger) Summary: debug info file descriptor of tarfile is inconsistent Initial Comment: "7.19.1 TarFile Objects" says The messages are written to sys.stdout. but they are actually written to sys.stderr :: def _dbg(self, level, msg): """Write debugging output to sys.stderr. """ if level <= self.debug: print >> sys.stderr, msg There are 2 options: (a) change document from stdout to stderr. (b) rewrite the code to use stdout. Given this is debug messages and most other modules use stdout for debug printing(gc is one of the few exceptions?), I'm +1 on (b). [*] http://docs.python.org/lib/tarfile-objects.html -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-11 08:19 Message: Logged In: YES user_id=1188172 Attaching patches for both tarfile and zipfile. For tarfile, the docs are changed to stderr, for zipfile, both docs and implementation are changed to stderr. Since I don't assume that someone actually uses the debug info in some automated way, I think we can correct this in 2.5. Raymond, please review. -- Comment By: George Yoshida (quiver) Date: 2005-07-10 18:26 Message: Logged In: YES user_id=671362 OK. I tested some GNU compression/decompression tools and comfirmed that they write debugging messages (displayed in verbose mode(-v)) to stderr. Now I'm leaning toward Reinhold's idea. > What about zipfile? > Should we print debug info to stderr there, too? Maybe yes. I'd be happy to volunteer for that patch. -- Comment By: Lars Gustäbel (gustaebel) Date: 2005-07-10 10:00 Message: Logged In: YES user_id=642936 This is a documentation error. Debug messages must go to stderr because that's what stderr is for. Think of a script that writes a tar archive to stdout for use in a unix shell pipeline. If debug messages went to stdout, too, it would produce unusable output, because archive data and debug messages would be mixed. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-09 19:04 Message: Logged In: YES user_id=1188172 The documentation seems to be borrowed from zipfile, where the statement is true: debug info is written to stdout. I'm in favour of changing the docs to stderr for tarfile. What about zipfile? Should we print debug info to stderr there, too? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235266&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
