[issue1692335] Fix exception pickling: Move initial args assignment to BaseException.__new__
Jaroslav Pachola added the comment: To me it seems more like a bug fix - in Python 2.4 and older the pickling works well and the current 2.5 behavior really breaks existing code. That's why I plead for inclusion in 2.5.2; because this issue prevents our company to move to 2.5. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1692335 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1935] test_descr.py converted to unittest
Georg Brandl added the comment: The GHOP patch was now committed as r60521. -- nosy: +georg.brandl status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1935 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1692335] Fix exception pickling: Move initial args assignment to BaseException.__new__
Guido van Rossum added the comment: Understood. Can you get other developers on python-dev to weigh in? Maybe I am over-estimating the danger. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1692335 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
Mark Dickinson added the comment:
About Rational('3.') and Rational('.2'):
It's not so much to do with consistency with float and Decimal; more to do
with the fact that some people like to write floats these ways (which
presumably is why float and Decimal allow such input).
It occurs to me that if you also allow things like Rational('1e+100') then
conversions from Decimal to Rational could simply be spelled
Rational(str(decimal_instance))
eliminating the need for the special Decimal - Rational conversion method.
Anyway, I'll change the regex to allow '3.' and '.3'.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1682
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1997] unicode and string compare should not cause an exception
Aaron Watters added the comment: Okay. I haven't looked but this should be well documented somewhere because I found it very surprising (it crashed a large run somewhere in the middle). In the case of strings versus unicode I think it is possible to hack around this by catching the exceptional case and comparing character by character -- treating out of band characters as larger than all unicode characters. I don't see why this would cause any problems at any rate. -- Aaron Watters On Feb 1, 2008 6:47 PM, Guido van Rossum [EMAIL PROTECTED] wrote: Guido van Rossum added the comment: As I understand it comparisons between two objects should always work. Hi Aaron! Glad to see you're back. It used to be that way when you Jim wrote the first Python book. :-) Nowadays, comparisons *can* raise exceptions. Marc-Andre has explained why. In 3.0, this particular issue will go away due to a different treatment of Unicode, but many more cases will raise TypeError when is used. == and != will generally work, though there are no absolute guarantees. -- nosy: +gvanrossum resolution: - rejected status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1997 __ Added file: http://bugs.python.org/file9348/unnamed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1997 __Okay.nbsp; I haven#39;t looked but this should be well documentedbrsomewhere because I found it very surprising (it crashed a largebrrun somewhere in the middle).brbrIn the case of strings versus unicode I think it is possiblebr to hack around this by catching the exceptional case andbrcomparing character by character -- treating out of bandbrcharacters as larger than all unicode characters.nbsp; I don#39;tbrsee why this would cause any problems at any rate.br brnbsp;nbsp; -- Aaron Wattersbrbrdiv class=gmail_quoteOn Feb 1, 2008 6:47 PM, Guido van Rossum lt;a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/agt; wrote:brblockquote class=gmail_quote style=border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex; brGuido van Rossum added the comment:brdiv class=Ih2E3dbrgt; As I understand it comparisons between two objects shouldbrgt; always work.brbr/divHi Aaron! nbsp;Glad to see you#39;re back.brbrIt used to be that way when you amp; Jim wrote the first Python book. :-)br brNowadays, comparisons *can* raise exceptions. nbsp;Marc-Andre has explainedbrwhy. nbsp;In 3.0, this particular issue will go away due to a differentbrtreatment of Unicode, but many more cases will raise TypeError when lt; isbr used. nbsp;== and != will generally work, though there are no absolutebrguarantees.brbr--brnosy: +gvanrossumbrresolution: nbsp;-gt; rejectedbrstatus: open -gt; closedbrdivdiv/divdiv class=Wj3C7cbr __brTracker lt;a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/agt;brlt;a href=http://bugs.python.org/issue1997; target=_blankhttp://bugs.python.org/issue1997/agt;br __br/div/div/blockquote/divbr ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1757072] Zipfile robustness
Alan McIntyre added the comment: It would seem that such a zip file is not consistent with the spec (http://www.pkware.com/documents/casestudies/APPNOTE.TXT). My first reaction is that we shouldn't accept behavior outside the spec unless it's something that's done by many popular ZIP applications. However, if somebody can convince me that this is a deviation from the spec that we should support, I'll write a patch for it. :) -- nosy: +alanmcintyre _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1757072 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1997] unicode and string compare should not cause an exception
Changes by Guido van Rossum: Removed file: http://bugs.python.org/file9348/unnamed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1997 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1997] unicode and string compare should not cause an exception
Guido van Rossum added the comment: You should be grateful. :-) The error points out a bug in your program: you're mixing encoded and unencoded text. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1997 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
Mark Dickinson added the comment: Regex changed in r60530. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1682 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2000] Undefined symbols: _PyOS_mystrnicmp on Mac OS X
New submission from Alexander Belopolsky: On Mac OS X, make fails with the following error .. /usr/bin/ld: Undefined symbols: _PyOS_mystrnicmp collect2: ld returned 1 exit status make: *** [python.exe] Error 1 The attached patch fixes the issue. -- components: Build files: make-patch.diff messages: 62006 nosy: belopolsky severity: normal status: open title: Undefined symbols: _PyOS_mystrnicmp on Mac OS X type: compile error versions: Python 2.6 Added file: http://bugs.python.org/file9349/make-patch.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2000 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2000] Undefined symbols: _PyOS_mystrnicmp on Mac OS X
Mark Dickinson added the comment: I assume this is on OS X 10.4? I can't reproduce the failure on Leopard. -- nosy: +marketdickinson __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2000 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2000] Undefined symbols: _PyOS_mystrnicmp on Mac OS X
Alexander Belopolsky added the comment: Looks like an SVN problem on my end. I am getting a stale version of the makefile. Please close the issue as invalid. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2000 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2000] Undefined symbols: _PyOS_mystrnicmp on Mac OS X
Georg Brandl added the comment: Closing. -- nosy: +georg.brandl resolution: - invalid status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2000 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
Jeffrey Yasskin added the comment: I think '1e+100' would constitute feature creep at this point, but thanks for the suggestion, and the improvement in the readability of the regex! __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1682 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
Raymond Hettinger added the comment:
The rational constructor should accept decimals directly.
Rational(Decimal('3.1')) does not suffer the same representation error
problems as Rational(float('3.1')). The conversion from decimal is
lossless and does not depend on the decimal context. There is no need
for a separate constructor.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1682
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2001] Pydoc interactive browsing enhancement
New submission from Ron Adam: This patch removes the gui tk control panel and replaces it with a navigation bar on the served web pages. This offers a nicer user experience because one no longer needs to jump back and forth between windows. The navbar supports getting specific modules, searching modules, and returning to the main module index. I believe the file source view is safer also. Possible issues... + Restarting the server without ending it causes an error do to the port already being used. I think this is not new. + There may be some brakage if other applications depend on the tk interface, but I don't think any do. Or at least none that I know of. + I haven't tested this on windows. (It works well on Ubuntu 7.10) -- components: Library (Lib) files: pydocnotk.diff messages: 62012 nosy: ron_adam severity: normal status: open title: Pydoc interactive browsing enhancement type: rfe Added file: http://bugs.python.org/file9350/pydocnotk.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2001 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
Jeffrey Yasskin added the comment: I think Rational should handle all floating types as consistently as possible, whatever their radix or precision. It's unlikely that people will convert from them often anyway, especially from Decimal, so the shorter conversion from Decimal doesn't seem to outweigh the extra complexity in the constructor's behavior. If I turn out to be wrong about this, we can revisit it in 3.1. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1682 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2002] Make int() fall back to trunc()
New submission from Jeffrey Yasskin: Per http://mail.python.org/pipermail/python-dev/2008-January/076564.html. -- assignee: jyasskin messages: 62014 nosy: jyasskin priority: high severity: normal status: open title: Make int() fall back to trunc() type: behavior versions: Python 2.6, Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2002 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1914] test_plistlib fails
Changes by Christian Heimes: -- resolution: - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1914 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2003] Incorrect definition of new-style class
New submission from Thane Plummer: Python Reference Manual section 3.3 (p3 s2) contains the fragment A new-style class neither more nor less than a user-defined type. A well placed 2-letter verb would transform this sad little fragment into a delightful, pleasing, and ultimately useful sentence. -- components: Documentation messages: 62015 nosy: thaneplummer severity: minor status: open title: Incorrect definition of new-style class versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2003 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2004] tarfile extractall() allows local attacker to overwrite files while extracting
New submission from Michael Brown: python 2.5.1 tarfile.py line 1516 in extractall() sets directories created to world-writeable while extracting which means an attacker can change/modify files before perms are fixed. Suggest 770 while extracting to fix. -- components: Library (Lib) messages: 62016 nosy: mebrown severity: major status: open title: tarfile extractall() allows local attacker to overwrite files while extracting type: security versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2004 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2004] tarfile extractall() allows local attacker to overwrite files while extracting
Michael Brown added the comment: I can confirm that this issue has been addressed in trunk tarfile.py. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2004 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2004] tarfile extractall() allows local attacker to overwrite files while extracting
Alan McIntyre added the comment: I noticed that in the trunk, ZipFile._extract_member, at line 865, still uses 777 (the default of os.makedirs) to create directories. I attached a patch for it. A quick grep shows that tarfile still uses the default permissions for os.makedirs and mkdir. Should these all be changed to 700? -- nosy: +alanmcintyre Added file: http://bugs.python.org/file9351/zipfile-dirperm.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2004 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2002] Make int() fall back to trunc()
Jeffrey Yasskin added the comment: Here's a patch to implement the fallback for both int and long. I'm pretty sure that _PyNumber_ConvertIntegralToInt() is in the wrong place. Where would be a better place for it? -- keywords: +patch nosy: +rhettinger Added file: http://bugs.python.org/file9352/int_fall_back_to_trunc.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2002 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1294959] Problems with /usr/lib64 builds.
Changes by Ignacio Vazquez-Abrams: -- nosy: +ivazquez _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1294959 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2002] Make int() fall back to trunc()
Raymond Hettinger added the comment: Guido, are these basically the mechanics you intended? All calls to PyNumber_Int() and PyNumber_Long() attempt the usual path and if those would fail, it tries __trunc__ if it exists and coerces the result of that call back to an int or long. The logic looks basically correct, but I'm not sure what it buys us since the returned Integral has to be converted back to an int or long anyway. On the plus side, it does not slow down the common case where PyNumber_Int() and PyNumberLong() would ordinarily succeed. An alternative to this patch would be to have math.trunc() try to return __trunc__() and if it doesn't exist, fallback to __int__. That avoids having arbitrary Integrals forced back into ints/longs, but it may not be what you guys were after. Either way will allow a user to define a __trunc__() method and have math.trunc() return an arbitrary Integral, not necessarily and int or long. There is also part of this patch that touches classobject.c but I'm not yet sure what the visible effect of that change would be or what the change was hoping to accomplish. -- assignee: jyasskin - gvanrossum nosy: +gvanrossum __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2002 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
