[issue3112] implement PEP 3134 exception reporting
Adam Olsen [EMAIL PROTECTED] added the comment: * cause/context cycles should be avoided. Naive traceback printing could become confused, and I can't think of any accidental way to provoke it (besides the problem mentioned here.) * I suspect PyErr_Display handled string exceptions in 2.x, and this is an artifact of that * No opinion on PyErr_DisplaySingle * PyErr_Display is used by PyErr_Print, and it must end up with no active exception. Additionally, third party code may depend on this semantic. Maybe PyErr_DisplayEx? * +1 on standardizing tracebacks -- nosy: +Rhamphoryncus ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3112 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3167] math test fails on Solaris 10
Mark Dickinson [EMAIL PROTECTED] added the comment: I'll take a look. -- assignee: - marketdickinson nosy: +marketdickinson ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3167 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3168] cmath test fails on Solaris 10
Changes by Mark Dickinson [EMAIL PROTECTED]: -- assignee: - marketdickinson nosy: +marketdickinson ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3168 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3167] math test fails on Solaris 10
Mark Dickinson [EMAIL PROTECTED] added the comment:
Could you tell me what
import math
math.log(float('-inf'))
gives instead of the expected ValueError?
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3167
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2722] os.getcwd fails for long path names on linux
Facundo Batista [EMAIL PROTECTED] added the comment: Went for the malloc only patch. Just fixed a small detail (weird corner case if malloc returned NULL first time, res will be unassigned). The test could be better (no necessity of using a recursive function, it could be done with a while), but it works. Commited in r64452. -- nosy: +facundobatista resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2722 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2732] curses.textpad loses characters at the end of lines
A.M. Kuchling [EMAIL PROTECTED] added the comment: This bug was fixed in 2.5 and 2.6, in rev. 60118 and 60119. Thanks for your bug report! -- assignee: - akuchling nosy: +akuchling resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2732 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3112] implement PEP 3134 exception reporting
Antoine Pitrou [EMAIL PROTECTED] added the comment: Le dimanche 22 juin 2008 à 07:04 +, Adam Olsen a écrit : Adam Olsen [EMAIL PROTECTED] added the comment: * cause/context cycles should be avoided. Naive traceback printing could become confused, and I can't think of any accidental way to provoke it (besides the problem mentioned here.) You mean they should be detected when the exception is set? I was afraid that it may make exception raising slower. Reporting is not performance sensitive in comparison to exception raising. (the problem mentioned here is already avoided in the patch, but the detection of other cycles is deferred to exception reporting for the reason given above) * PyErr_Display is used by PyErr_Print, and it must end up with no active exception. Additionally, third party code may depend on this semantic. Maybe PyErr_DisplayEx? I was not proposing to change the exception swallowing semantics, just to add a return value indicating if any errors had occurred while displaying the exception. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3112 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3165] cPickle recursion problem
Facundo Batista [EMAIL PROTECTED] added the comment: What is this fixing? Could you please provide a test cases that fails without this patch? Thank you!! -- nosy: +facundobatista ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3165 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1974] email.MIMEText.MIMEText.as_string incorrectly folding long subject header
Chris Withers [EMAIL PROTECTED] added the comment: Andi, I'm in total agreement with you :-) (so if this bug could get fixed, both issues could get closed) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1974 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3112] implement PEP 3134 exception reporting
Adam Olsen [EMAIL PROTECTED] added the comment: On Sun, Jun 22, 2008 at 8:07 AM, Antoine Pitrou [EMAIL PROTECTED] wrote: You mean they should be detected when the exception is set? I was afraid that it may make exception raising slower. Reporting is not performance sensitive in comparison to exception raising. (the problem mentioned here is already avoided in the patch, but the detection of other cycles is deferred to exception reporting for the reason given above) I meant only that trivial cycles should be detected. However, I hadn't read your patch, so I didn't realize you already knew of a way to create a non-trivial cycle. This has placed a niggling doubt in my mind about chaining the exceptions, rather than the tracebacks. Hrm. * PyErr_Display is used by PyErr_Print, and it must end up with no active exception. Additionally, third party code may depend on this semantic. Maybe PyErr_DisplayEx? I was not proposing to change the exception swallowing semantics, just to add a return value indicating if any errors had occurred while displaying the exception. Ahh, harmless then, but to what benefit? Wouldn't the traceback module be better suited to any possible error reporting? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3112 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3085] chapter 17.1.3.5 'Replacing os.popen*' in the Python library reference contains an error
Georg Brandl [EMAIL PROTECTED] added the comment: Fixed in r64461. Thanks! -- resolution: - fixed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3085 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3157] sqlite3 minor documentation issues
Georg Brandl [EMAIL PROTECTED] added the comment: I fixed the docstring in r64463 (2.5 branch, already fixed in trunk) and expanded the connect() docstring in r64464. -- resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3157 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3085] chapter 17.1.3.5 'Replacing os.popen*' in the Python library reference contains an error
Manuel Kaufmann [EMAIL PROTECTED] added the comment: This bug was reported on Python 2.5 version and was applied on 2.6 branch. That's correct? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3085 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3146] Sphinx/LaTeX fails on Python 3.0b1 documentation
Georg Brandl [EMAIL PROTECTED] added the comment: Thanks, should be fixed with Sphinx r64465. -- resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3146 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3085] chapter 17.1.3.5 'Replacing os.popen*' in the Python library reference contains an error
Georg Brandl [EMAIL PROTECTED] added the comment: I don't maintain the 2.5 docs anymore, at least for such minor bugs. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3085 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3112] implement PEP 3134 exception reporting
Adam Olsen [EMAIL PROTECTED] added the comment: On Sun, Jun 22, 2008 at 1:04 PM, Antoine Pitrou [EMAIL PROTECTED] wrote: Antoine Pitrou [EMAIL PROTECTED] added the comment: Le dimanche 22 juin 2008 à 17:17 +, Adam Olsen a écrit : I meant only that trivial cycles should be detected. However, I hadn't read your patch, so I didn't realize you already knew of a way to create a non-trivial cycle. This has placed a niggling doubt in my mind about chaining the exceptions, rather than the tracebacks. Hrm. Chaining the tracebacks rather than the exceptions loses important information: what is the nature of the exception which is the cause or context of the current exception? I assumed each leg of the traceback would reference the relevant exception. Although.. this is effectively the same as creating a new exception instance when reraised, rather than modifying the old one. Reusing the old is done for performance I believe. It is improbable to create such a cycle involuntarily, it means you raise an old exception in replacement of a newer one caused by the older, which I think is quite contorted. It is also quite easy to avoid creating the cycle, simply by re-raising outside of any except handler. I'm not convinced. try: ... # Lookup except A as a: # Lookup failed try: ... # Fallback except B as b: # Fallback failed raise a # The original exception is of the type we want For this behaviour, this is the most natural way to write it. Conceptually, there shouldn't be a cycle - the traceback should be the lookup, then the fallback, then whatever code is about this - exactly the order the code executed in. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3112 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1523853] 2.4.2 file.read caches EOF state
Facundo Batista [EMAIL PROTECTED] added the comment: In Linux, it seems to be the behaviour of the underlying C function 'fread'. Do you think it's ok to add the following line in the read() documentation? As this function depends of the underlying C function :cfunc:`fread`, inheritates its behaviour in details like caching EOF and others. Assigning this to George, to reword that in nicer English and apply. Regards, -- assignee: - georg.brandl nosy: +facundobatista, georg.brandl ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1523853 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3112] implement PEP 3134 exception reporting
Antoine Pitrou [EMAIL PROTECTED] added the comment: Le dimanche 22 juin 2008 à 19:23 +, Adam Olsen a écrit : For this behaviour, this is the most natural way to write it. Conceptually, there shouldn't be a cycle I agree your example is not far-fetched. How about avoiding cycles for implicit chaining, and letting users shoot themselves in the foot with explicit recursive chaining if they want? Detection would be cheap enough, just a simple loop without any memory allocation. the traceback should be the lookup, then the fallback, then whatever code is about this - exactly the order the code executed in. It would be the reverse: first the fallback, then the re-raised exception. The last caught exception is always reported last, because it's supposed to be the main or highest-level one. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3112 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3112] implement PEP 3134 exception reporting
Adam Olsen [EMAIL PROTECTED] added the comment: On Sun, Jun 22, 2008 at 1:48 PM, Antoine Pitrou [EMAIL PROTECTED] wrote: Antoine Pitrou [EMAIL PROTECTED] added the comment: Le dimanche 22 juin 2008 à 19:23 +, Adam Olsen a écrit : For this behaviour, this is the most natural way to write it. Conceptually, there shouldn't be a cycle I agree your example is not far-fetched. How about avoiding cycles for implicit chaining, and letting users shoot themselves in the foot with explicit recursive chaining if they want? Detection would be cheap enough, just a simple loop without any memory allocation. That's still O(n). I'm not so easily convinced it's cheap enough. And for that matter, I'm not convinced it's correct. The inner exception's context becomes clobbered when we modify the outer exception's traceback. The inner's context should reference the traceback as it was at that point. This would all be a lot easier if reraising always created a new exception. Can you think of a way to skip that only when we can be sure its safe? Maybe as simple as counting the references to it? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3112 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3112] implement PEP 3134 exception reporting
Antoine Pitrou [EMAIL PROTECTED] added the comment: Le dimanche 22 juin 2008 à 19:57 +, Adam Olsen a écrit : That's still O(n). I'm not so easily convinced it's cheap enough. O(n) when n will almost never be greater than 5 (and very often equal to 1 or 2), and when the unit is the cost of a pointer dereference plus the cost of a pointer comparison, still sounds cheap. We could bench it anyway. And for that matter, I'm not convinced it's correct. The inner exception's context becomes clobbered when we modify the outer exception's traceback. The inner's context should reference the traceback as it was at that point. Yes, I've just thought about that, it's a bit annoying... We have to decide what is more annoying: that, or a reference cycle that can delay deallocation of stuff attached to an exception (including local variables attached to the tracebacks)? (just a small note: it's exception objects that are chained, not tracebacks... we never modify tracebacks at any point) This would all be a lot easier if reraising always created a new exception. How do you duplicate an instance of an user-defined exception? Using an equivalent of copy.deepcopy()? It will probably end up much more expensive than the above-mentioned O(n) search. Can you think of a way to skip that only when we can be sure its safe? Maybe as simple as counting the references to it? I don't think so, the exception can be referenced in an unknown number of local variables (themselves potentially referenced by tracebacks). ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3112 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3112] implement PEP 3134 exception reporting
Adam Olsen [EMAIL PROTECTED] added the comment: On Sun, Jun 22, 2008 at 2:20 PM, Antoine Pitrou [EMAIL PROTECTED] wrote: Antoine Pitrou [EMAIL PROTECTED] added the comment: Le dimanche 22 juin 2008 à 19:57 +, Adam Olsen a écrit : That's still O(n). I'm not so easily convinced it's cheap enough. O(n) when n will almost never be greater than 5 (and very often equal to 1 or 2), and when the unit is the cost of a pointer dereference plus the cost of a pointer comparison, still sounds cheap. We could bench it anyway. Indeed. And for that matter, I'm not convinced it's correct. The inner exception's context becomes clobbered when we modify the outer exception's traceback. The inner's context should reference the traceback as it was at that point. Yes, I've just thought about that, it's a bit annoying... We have to decide what is more annoying: that, or a reference cycle that can delay deallocation of stuff attached to an exception (including local variables attached to the tracebacks)? The cycle is only created by broken behaviour. The more I think about it, the more I want to fix it (by not reusing the exception). This would all be a lot easier if reraising always created a new exception. How do you duplicate an instance of an user-defined exception? Using an equivalent of copy.deepcopy()? It will probably end up much more expensive than the above-mentioned O(n) search. Passing in e.args is probably sufficient. All this would need to be discussed on python-dev (or python-3000?) though. Can you think of a way to skip that only when we can be sure its safe? Maybe as simple as counting the references to it? I don't think so, the exception can be referenced in an unknown number of local variables (themselves potentially referenced by tracebacks). Can be, or will be? Only the most common behaviour needs to be optimized. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3112 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3112] implement PEP 3134 exception reporting
Antoine Pitrou [EMAIL PROTECTED] added the comment: Le dimanche 22 juin 2008 à 20:40 +, Adam Olsen a écrit : How do you duplicate an instance of an user-defined exception? Using an equivalent of copy.deepcopy()? It will probably end up much more expensive than the above-mentioned O(n) search. Passing in e.args is probably sufficient. I think it's very optimistic :-) Some exception objects can hold dynamic state which is simply not stored in the args tuple. See Twisted's Failure objects for an extreme example: http://twistedmatrix.com/trac/browser/trunk/twisted/python/failure.py (yes, it is used an an exception: see raise self in the trap() method) Can be, or will be? Only the most common behaviour needs to be optimized. Well, the most common behaviour is a very short context chain, which is already optimized by my reference-avoidance proposal... ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3112 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1567948] poplib.py list interface
Facundo Batista [EMAIL PROTECTED] added the comment: Hasan, are you still interested in this or wants to drop this request? Passing almost two years without comments it's no good if you'll be the package maintainer. Thanks! -- nosy: +facundobatista ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1567948 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue678464] Docs don't define sequence-ness very well
Facundo Batista [EMAIL PROTECTED] added the comment: Skip, don't you think it's better to raise this kind of generic question in the python-dev list? This should probably lay down here for ever before a discussion raises to decide this. -- nosy: +facundobatista ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue678464 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue701743] Reloading pseudo modules
Facundo Batista [EMAIL PROTECTED] added the comment: Walter, the import mechanisms changed by a big rework from Brett Cannon in the last months. Do you think still have a use case that should be fulfilled? Do you want to update your patch? Thank you! -- nosy: +facundobatista ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue701743 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3051] heapq change breaking compatibility
Changes by Raymond Hettinger [EMAIL PROTECTED]: -- status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3051 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3069] Let set.union and set.intersection accept multiple arguments
Changes by Raymond Hettinger [EMAIL PROTECTED]: -- status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1746088] long.__str__ is quadratic time
Raymond Hettinger [EMAIL PROTECTED] added the comment: Still waiting for the patch. -- assignee: rhettinger - ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1746088 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2702] pickling of large recursive structures crashes cPickle
Facundo Batista [EMAIL PROTECTED] added the comment: Could you please tell me if this problem arises with this test? -- keywords: +patch nosy: +facundobatista Added file: http://bugs.python.org/file10701/test_cpickle.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2702 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2702] pickling of large recursive structures crashes cPickle
Daniel Darabos [EMAIL PROTECTED] added the comment: I have just quickly pasted it into an interpreter. 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. class Node(object): ... pass ... nodes = [Node() for i in range(500)] for n in nodes: ... n.connections = list(nodes) ... n.connections.remove(n) ... import cPickle s = cPickle.dumps( n ) After this line, the interpreter terminated without any further output (no Python exception and no Windows General Exception message box either). Is it sufficient, or would you prefer me to run the test properly? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2702 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2702] pickling of large recursive structures crashes cPickle
Facundo Batista [EMAIL PROTECTED] added the comment: Daniel, it'd be great, because it does not crash in linux, so I can not test it... and I have a patch to apply (see issue 3165), so I wanted to test it that way. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2702 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue775340] OSX 'freeze' bug
Facundo Batista [EMAIL PROTECTED] added the comment: Justin, Jack, how this evolved to the newer Python versions? Do you think it's worth it to keep it open? Thank you! -- nosy: +facundobatista ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue775340 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2702] pickling of large recursive structures crashes cPickle
Daniel Darabos [EMAIL PROTECTED] added the comment: It works for me as a test case too: test_deep_recursive (__main__.cPickleDeepRecursive) ... ERROR == ERROR: test_deep_recursive (__main__.cPickleDeepRecursive) -- Traceback (most recent call last): File c:\devel\Python25\Lib\test\test_cpickle.py, line 107, in test_deep_recursive self.assertRaises(RuntimeError, cPickle.dumps, n) File C:\devel\Python25\lib\unittest.py, line 320, in failUnlessRaises callableObj(*args, **kwargs) KeyError: 13352688 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2702 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1003935] xrange overflows
Raymond Hettinger [EMAIL PROTECTED] added the comment: This was fixed for Py3.0. No interest was shown in backporting. -- resolution: - out of date status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1003935 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3172] test macos skipped unexpected on linux2
New submission from Jean Brouwers [EMAIL PROTECTED]: Test test_macos is reported as an unexpected skip on linux2 by Python 2.6b1 make test. 35 tests skipped: ... test_macos test_macostools ... ... 2 skips unexpected on linux2: test_tcl test_macos $ uname -a Linux ... 2.6.9-11.EL #1 Fri May 20 18:17:57 EDT 2005 i686 i686 i386 GNU/Linux $ gcc -v Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.6/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man -- infodir=/usr/share/info --enable-shared --enable-threads=posix -- disable-checking --with-system-zlib --enable-__cxa_atexit --disable- libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux Thread model: posix gcc version 3.4.6 20060404 (Red Hat 3.4.6-9) -- components: Tests messages: 68593 nosy: MrJean1 severity: normal status: open title: test macos skipped unexpected on linux2 type: behavior versions: Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3172 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3167] math test fails on Solaris 10
Jean Brouwers [EMAIL PROTECTED] added the comment:
Here is that in from 32- and 64-bit Python 2.6b1:
./python (32-bit)
Python 2.6b1 (r26b1:64398, Jun 20 2008, 09:20:49) [C] on sunos5
Type help, copyright, credits or license for more information.
import math
math.log(float('-inf'))
-inf
math.log(float('inf'))
inf
math.log(float('nan'))
nan
./python (64-bit)
Python 2.6b1 (r26b1:64398, Jun 19 2008, 20:27:39) [C] on sunos5
Type help, copyright, credits or license for more information.
import math
math.log(float('-inf'))
Traceback (most recent call last):
File stdin, line 1, in module
ValueError: math domain error
math.log(float('inf'))
inf
math.log(float('nan'))
nan
Look like a Sun issue, doesn't it?
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3167
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3165] cPickle recursion problem
Daniel Darabos [EMAIL PROTECTED] added the comment: Added lines have to come after the static char... declarations to comply with C. Unfortunately I am not experienced with building Python on Windows, so I could not really try the patch, sorry. (I can get a cPickle.pyd, but it does not replace the built-in cPickle module.) Anyway, thanks for the patch, I hope it fixes my issue (#2702). -- nosy: +cyhawk ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3165 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2813] No float formatting in PyString_FromFormat
Jean Brouwers [EMAIL PROTECTED] added the comment: Attached is another patch for file Objects/stringobject.c(relative to Python 2.6b1) which supports the double %f and long double %LF formats. However, %Lf is included only if symbol LDBL_DIG is defined in header file float.h on the underlying platform. This patch also handles the long and size_t flags correctly in the first loop to determine the size of the buffer under ... case 'd': case 'u': case 'i': case 'x': ... Btw, it does not make sense to handle float since there is not formnat specification for floats. Added file: http://bugs.python.org/file10702/stringobject_format_Lf.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2813 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2813] No float formatting in PyString_FromFormat
Changes by Jean Brouwers [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file10702/stringobject_format_Lf.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2813 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2813] No float formatting in PyString_FromFormat
Changes by Jean Brouwers [EMAIL PROTECTED]: Added file: http://bugs.python.org/file10703/stringobject_format_Lf.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2813 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2813] No float formatting in PyString_FromFormat
Facundo Batista [EMAIL PROTECTED] added the comment: Jean, you can increase *hugely* the possibility of this being accepted if you submit a comprehensive suite test for this. Thanks!! -- nosy: +facundobatista ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2813 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3085] chapter 17.1.3.5 'Replacing os.popen*' in the Python library reference contains an error
Changes by Benjamin Peterson [EMAIL PROTECTED]: -- status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3085 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3172] test macos skipped unexpected on linux2
Benjamin Peterson [EMAIL PROTECTED] added the comment: This was fixed on the trunk by r64408. -- nosy: +benjamin.peterson resolution: - out of date status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3172 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1180470] BaseHTTPServer uses deprecated mimetools.Message
Benjamin Peterson [EMAIL PROTECTED] added the comment: Let's save ourselves the trouble... -- nosy: +benjamin.peterson resolution: - out of date status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1180470 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1534607] IndexError: Add bad index to msg
Changes by Benjamin Peterson [EMAIL PROTECTED]: -- resolution: - invalid status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1534607 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1534607] IndexError: Add bad index to msg
Changes by Benjamin Peterson [EMAIL PROTECTED]: -- resolution: invalid - status: closed - open ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1534607 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2683] subprocess.Popen.communicate takes bytes, not str
Benjamin Peterson [EMAIL PROTECTED] added the comment: I say docs. -- assignee: - georg.brandl components: +Documentation -Extension Modules nosy: +benjamin.peterson, georg.brandl ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2683 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3161] Missing import for sys in _abcoll
Changes by Benjamin Peterson [EMAIL PROTECTED]: -- assignee: - rhettinger nosy: +rhettinger ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3161 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2702] pickling of large recursive structures crashes cPickle
Facundo Batista [EMAIL PROTECTED] added the comment: Commited this patch to the test cases, and the patch from #3165 to fix the problem, thank you all! -- resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2702 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3165] cPickle recursion problem
Facundo Batista [EMAIL PROTECTED] added the comment: Applied this patch. Daniel, don't know about that rule... I didn't get any warning with gcc... Anyway, this fixes the issue of #2702. Thanks cuerty! -- resolution: - accepted status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3165 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3173] external strftime for Python?
New submission from Skip Montanaro [EMAIL PROTECTED]: Back in April we had a thread on xmlrpclib's problematic handling of dates before 1900: http://thread.gmane.org/gmane.comp.python.devel/93273/focus=93309 I'm still of the opinion that strftime() is the culprit and xmlrpclib is just an innocent bystander. Guido worried that to correct this we'd have to implement strftime() from scratch. I took a different approach and scouted around for an existing version of strftime() which we could suck into the distribution. I found a modified version of the BSD 4.4 strftime which came with (I see to recall) Tcl. The attached patch is against the py3k svn repo. It passes all tests as far as I can tell. Also, see http://bugs.python.org/issue1777412 which appears to be related. -- files: strftime.diff keywords: patch, patch messages: 68603 nosy: skip.montanaro priority: normal severity: normal status: open title: external strftime for Python? versions: Python 3.0 Added file: http://bugs.python.org/file10704/strftime.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3173 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3173] external strftime for Python?
Skip Montanaro [EMAIL PROTECTED] added the comment: Ummm... I think I only modified timemodule.c. datetimemodule.c probably needs a tweak as well. I need to get this off my desk though. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3173 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3161] Missing import for sys in _abcoll
Raymond Hettinger [EMAIL PROTECTED] added the comment: Applied in r64475 . Thanks for the patch. -- resolution: - accepted status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3161 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3173] external strftime for Python?
Martin v. Löwis [EMAIL PROTECTED] added the comment: So how does it work for non-English locales? -- nosy: +loewis ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3173 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3142] urllib docs don't match the new modules
Senthil [EMAIL PROTECTED] added the comment: Hi Georg, Updated all the required docs and Committed revision 64476. Let me know if any more changes required. Thanks, Senthil ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3142 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2885] Create the urllib package
Senthil [EMAIL PROTECTED] added the comment: - Docs updated. - Still pending: 2to3 updates and Deprecation warnings. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2885 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2813] No float formatting in PyString_FromFormat
Jean Brouwers [EMAIL PROTECTED] added the comment: Another rev of the patch now including updates to 2 documentation files: Doc/c-api/exceptions.rst and Doc/c-api/string.rst. As before the patch is relative to the source of Python 2.6b1. Where should test cases for the new formats in the PyString_FromFormat* and PyErr_Format functions be added? Added file: http://bugs.python.org/file10705/stringobject_format_Lf.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2813 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2813] No float formatting in PyString_FromFormat
Changes by Jean Brouwers [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file10703/stringobject_format_Lf.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2813 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
