[issue1754483] linecache package handling
Kevin Goodsell [EMAIL PROTECTED] added the comment: Here's a small test script. Added file: http://bugs.python.org/file10813/test.py ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1754483 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3008] Let bin/oct/hex show floats
Mark Dickinson [EMAIL PROTECTED] added the comment: In the interests of getting early feedback, here's half a patch, containing an implementation of from.fromhex and tests. Still to come: float.hex and documentation. I'll ask on python-dev about C99 and %a. Added file: http://bugs.python.org/file10814/hex_float.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3008 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3008] Let bin/oct/hex show floats
Mark Dickinson [EMAIL PROTECTED] added the comment: containing an implementation of from.fromhex and tests. That should be 'float.fromhex', not 'from.fromhex'. I should also have said that this patch is against the trunk; only minor changes should be required for py3k. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3008 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1754483] linecache package handling
Changes by Georg Brandl [EMAIL PROTECTED]: -- assignee: - georg.brandl nosy: +georg.brandl ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1754483 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2663] shutil.copytree glob-style filtering [patch]
Georg Brandl [EMAIL PROTECTED] added the comment: Committed in r64722. Thanks everyone! -- resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2663 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3288] float.as_integer_ratio method is not documented
New submission from Mark Dickinson [EMAIL PROTECTED]: The float.as_integer_ratio method needs to be documented somewhere other than whatsnew/2.6.rst. -- assignee: georg.brandl components: Documentation messages: 69277 nosy: georg.brandl, marketdickinson severity: normal status: open title: float.as_integer_ratio method is not documented versions: Python 2.6, Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3288 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3008] Let bin/oct/hex show floats
Mark Dickinson [EMAIL PROTECTED] added the comment: Here's an updated patch, complete with both float methods and documentation. Added file: http://bugs.python.org/file10815/hex_float2.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3008 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1754483] linecache package handling
Hans Ulrich Niedermann [EMAIL PROTECTED] added the comment: Even with that patch, I'm still getting backtraces similar to this: Traceback (most recent call last): File /home/user/foo/src/foo, line 83, in module foomain(sys.argv) File /home/uli/foo/src/foo, line 79, in foomain foolib.main.cmdmain(sys.argv) File ./foolib/main.py, line 250, in cmdmain File ./foolib/main.py, line 199, in main File ./foolib/main.py, line 180, in __init__ File ./foolib/main.py, line 115, in __get__ AttributeError: property--48216a94 Looks like I should write a dozen test cases I can think of on my own. :) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1754483 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3008] Let bin/oct/hex show floats
Mark Dickinson [EMAIL PROTECTED] added the comment: Add updated patch with expanded documentation. Added file: http://bugs.python.org/file10816/hex_float2.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3008 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3008] Let bin/oct/hex show floats
Changes by Mark Dickinson [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file10815/hex_float2.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3008 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3188] float('infinity') should be valid
Mark Dickinson [EMAIL PROTECTED] added the comment: Checked in, r64729. -- resolution: - accepted status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3188 ___ ___ 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
Mark Dickinson [EMAIL PROTECTED] added the comment: Thanks, Jean. I've checked in your workaround in r64735. Leaving this open for now as a reminder about finite/is_finite. -- resolution: - fixed ___ 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
[issue3139] bytearrays are not thread safe
Antoine Pitrou [EMAIL PROTECTED] added the comment: If I try to follow the chain the consequences: - all PyArg_ParseTuple(s#) calls that release the GIL afterwards should be re-written to use another API (which one I don't know exactly, but hopefully the appropriate functions are already provided by the buffer API); this applies to third-party extension modules as well - consequently, forward compatibility is broken in an important way (but it would probably be ok for py3k) - perhaps the bytearray type should not have been backported to 2.6, or perhaps it should carry a big warning in the documentation ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3139 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3139] bytearrays are not thread safe
Antoine Pitrou [EMAIL PROTECTED] added the comment: By the way, here's a more reliable way to make it crash (on my Linux machine): import bz2, threading bz2c = bz2.BZ2Compressor() # Span at least a whole arena (256KB long) junk_len = 512 * 1024 junk = ba * junk_len buf = bytearray() for x in range(50): buf[:] = junk t = threading.Thread(target=bz2c.compress, args=[buf]) t.start() buf[:] = b t.join() ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3139 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3139] bytearrays are not thread safe
Antoine Pitrou [EMAIL PROTECTED] added the comment: Now I've just discovered there is the same problem with the array.array() type (see following code). import bz2, threading, array bz2c = bz2.BZ2Compressor() # Span at least a whole arena (256KB long) junk_len = 512 * 1024 junk = array.array(c, ba) * junk_len empty = array.array(c) buf = empty[:] for x in range(50): buf[:] = junk t = threading.Thread(target=bz2c.compress, args=[buf]) t.start() buf[:] = empty t.join() ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3139 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3290] python-config --cflags includes irrelevant flags
New submission from Sacha Varma [EMAIL PROTECTED]: As I understand it, python-config --cflags is intended to yield the C compiler flags needed to compile a program that uses Python headers and libraries (as opposed to the C flags needed to compile python itself). However, it seems to include irrelevant options such as -Wall and -O3, which interfere with the build (for example, by enabling optimisation in a debug build): $ python-config --cflags -I/opt/Python-2.5.1/include/python2.5 -I/opt/Python-2.5.1/include/python2.5 -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -- components: Build messages: 69289 nosy: sacha severity: normal status: open title: python-config --cflags includes irrelevant flags type: behavior versions: Python 2.5 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3290 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3289] unnecessary call to time and localtime slows time.mktime
Facundo Batista [EMAIL PROTECTED] added the comment: Commited in r64745. Thanks for this patch! -- nosy: +facundobatista resolution: - accepted status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3289 ___ ___ 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
Mark Dickinson [EMAIL PROTECTED] added the comment: There is another, perhaps related issue on Solaris. The compiler warns that function finite is implicitly defined. Commenting out this line in pyconfig.h as /* #define HAVE_FINITE 1 */ make that warning go away. If there is no function finite, why is HAVE_FINITE defined at all? I don't think this is too serious. My guess would be that both finite and isfinite (which is the C99-recommended way to spell finite) are implemented in libm, but that only isfinite is mentioned in math.h (or possibly that finite is mentioned is math.h but is ifdef'd out as a result of some particular compiler options). So a code snippet that refers to 'finite' emits a warning, but compiles fine. Hence the corresponding autoconf test passes, and autoconf sets HAVE_FINITE to 1. And the Python build also emits a warning, but compiles and runs fine. Could you take a look in the 'config.log' file after configuring and see whether the 'implicit definition of finite' warning is in there as well? The right fix is probably to rework things to use 'isfinite' in preference to 'finite'. I'm not sure that Windows has isfinite, though. -- status: open - closed ___ 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
[issue3290] python-config --cflags includes irrelevant flags
Martin v. Löwis [EMAIL PROTECTED] added the comment: Georg, what do you think? -- assignee: - georg.brandl nosy: +georg.brandl, loewis ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3290 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3291] rlcompleter doesn't work anymore
New submission from Antoine Pitrou [EMAIL PROTECTED]: In the latest py3k versions, rlcompleter doesn't work anymore. Pressing the tab key (with tab-completion enabled) doesn't produce anything on screen. -- components: Library (Lib) messages: 69293 nosy: pitrou severity: normal status: open title: rlcompleter doesn't work anymore type: behavior versions: Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3291 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3291] rlcompleter doesn't work anymore
Benjamin Peterson [EMAIL PROTECTED] added the comment: Antoine, can you try it before r64671? -- nosy: +benjamin.peterson ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3291 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3239] curses/textpad.py incorrectly and redundantly imports ascii
Facundo Batista [EMAIL PROTECTED] added the comment: Commited in r64746. Thank you!! -- resolution: - accepted status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3239 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3291] rlcompleter doesn't work anymore
Antoine Pitrou [EMAIL PROTECTED] added the comment: Le samedi 05 juillet 2008 à 20:32 +, Benjamin Peterson a écrit : Benjamin Peterson [EMAIL PROTECTED] added the comment: Antoine, can you try it before r64671? Bingo, the regression occurs exactly at r64671. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3291 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3291] rlcompleter doesn't work anymore
Antoine Pitrou [EMAIL PROTECTED] added the comment: Here is a fix (in addition to the one you already committed). -- keywords: +patch Added file: http://bugs.python.org/file10820/rlcompleter.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3291 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3291] rlcompleter doesn't work anymore
Benjamin Peterson [EMAIL PROTECTED] added the comment: Thanks for the report and the fix! (committed in r64748) -- resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3291 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2834] re.IGNORECASE not Unicode-ready
Antoine Pitrou [EMAIL PROTECTED] added the comment: http://codereview.appspot.com/2439 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2834 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3292] Position index limit; s.insert(i,x) not same as s[i:i]=[x]
New submission from Terry J. Reedy [EMAIL PROTECTED]: Suggested changes to Lib Ref Manual: Sequence Types --...(3.6 for 2.5) (These are mostly based on an issue posted on c.l.p. The Plone Archetypes package (which I know nothing of) was reported as suggesting that users pass sys.maxint, to indicate 'insert at end', to one of their functions that uses .insert. A user with an AMD64 did that ... and I could not find doc proof that the crash was not a Python bug.) Main section: Before the operation list, change n, i and j are integers: to n, i, j, and k are integers: After the above, add An implementation may limit the range of position indexes (some uses of i below). I do not know if this limitation, actual for CPython is documented elsewhere, but it should be here. In particular, i is used as both position and slice index. Consider using i only as a magnitude-limited position index (an 'index-sized integer' as one error message puts it) and j,k,l for unlimited slice and other integers. This would slightly change the suggestions above and entail replacements in the table here and in following subsections. Mutable Sequence Types In 3.0, .count and .index are general sequence methods and should be moved up to that section. (For .index, parameters i j are not (limited) position indexes but simply integers for comparison. The notation change suggested above would make this clear without one having to experiment or infer from the comparison rule.) The line s.insert(i, x) same as s[i:i] = [x] is not true when i is outside the range of allow position indexes. If i is not defined as a limited range integer (and the implementation not changed ;-) add a footnote only when i is within the range of allowed position indexes. Is there a policy on documenting possible operation-specific exceptions? I consider them part of the interface. Or should I bring this up on pydev? For 3.0, footnotes 3 and 7 (in this subsection) document 2, for 4 different operations. Here are a couple more related to this issue. In the main section, for s[i]: 2.x IndexError: cannot fit 'long' into an index-sized integer 3.0 IndexError: cannot fit 'int' into an index-sized integer In the subsection, for s.insert(i,x): 2.x OverflowError: long int too large to convert to int 3.0 OverflowError: Python int too large to convert to C ssize_t I actually think the OverflowError should be changed to IndexError since the problem is the same in both cases, but that is a different issue. -- assignee: georg.brandl components: Documentation messages: 69302 nosy: georg.brandl, tjreedy severity: normal status: open title: Position index limit; s.insert(i,x) not same as s[i:i]=[x] versions: Python 2.5, Python 2.6, Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3292 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3293] incorrect comments for PyObject_ReleaseBuffer
New submission from Antoine Pitrou [EMAIL PROTECTED]: The declaration for PyObject_ReleaseBuffer (in Include/abstract.h) has the following comments attached to it. But the part about the return value is wrong since the function is defined as returning void. Also, PEP 3118 says it always succeeds so it can't return an error code. By the way, may I suggest that having the buffer API declared in abstract.h but the Py_buffer struct declared in object.h (and why not in bufferobject.h?) is slightly confusing. /* C-API version of the releasebuffer function call. It checks to make sure the object has the required function pointer and issues the call. The obj must have the buffer interface or this function will cause a segfault (i.e. it is assumed to be called only after a corresponding getbuffer which already verified the existence of the tp_as_buffer pointer). Returns 0 on success and -1 (with an error raised) on failure. This function always succeeds (as a NO-OP) if there is no releasebuffer function for the object so that it can always be called when the consumer is done with the buffer */ -- components: Interpreter Core messages: 69303 nosy: pitrou severity: normal status: open title: incorrect comments for PyObject_ReleaseBuffer versions: Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3293 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3139] bytearrays are not thread safe
Martin v. Löwis [EMAIL PROTECTED] added the comment: I believe the 2.6 s# processing works correctly; the error is in the bytearray object. This either shouldn't support the buffer interface, or it shouldn't reallocate the buffer after having returned a pointer to it. For 3k, convertbuffer shouldn't call bf_releasebuffer; instead, the caller of ParseTuple somehow needs to release the buffer. As a consequence, s# should refuse buffer objects who have a bf_releasebuffer operation, and another code might get added to fill out a Py_buffer - or s# can get changed to always produce a Py_buffer (which would affect the code significantly). -- nosy: +loewis ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3139 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3294] SVN repository contains an incorrect symbolic link
New submission from Antoine Pitrou [EMAIL PROTECTED]: In the py3k SVN branch I can see the following link. I suppose it is a mistake? $ ls -la Mac/IDLE/IDLE.app/Contents/MacOS/Python lrwxrwxrwx 1 antoine antoine 92 2008-07-01 22:33 Mac/IDLE/IDLE.app/Contents/MacOS/Python - /Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Python -- components: Build, Macintosh messages: 69305 nosy: pitrou severity: normal status: open title: SVN repository contains an incorrect symbolic link versions: Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3294 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3139] bytearrays are not thread safe
Antoine Pitrou [EMAIL PROTECTED] added the comment: For reference, here is a proof-of-concept patch which shows how to fix the bytearray crasher above (it raises a BufferError instead). Added file: http://bugs.python.org/file10822/bzcrash.py ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3139 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3139] bytearrays are not thread safe
Changes by Antoine Pitrou [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file10822/bzcrash.py ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3139 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3139] bytearrays are not thread safe
Changes by Antoine Pitrou [EMAIL PROTECTED]: Added file: http://bugs.python.org/file10823/bzcrash.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3139 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3294] SVN repository contains an incorrect symbolic link
Benjamin Peterson [EMAIL PROTECTED] added the comment: Fixed in r64749. -- assignee: - benjamin.peterson nosy: +benjamin.peterson resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3294 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3296] print function not executed in python 3.0 tutorial
New submission from Florian Mayer [EMAIL PROTECTED]: It is for sure only a minor issue, but the new tutorial should not confuse readers as the print function is not executed here and does not do anything at all. Patch is attached. -- assignee: georg.brandl components: Documentation files: doc-patch messages: 69311 nosy: georg.brandl, segfaulthunter severity: normal status: open title: print function not executed in python 3.0 tutorial versions: Python 3.0 Added file: http://bugs.python.org/file10824/doc-patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3296 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3295] PyExc_BufferError is declared but nowhere defined
Benjamin Peterson [EMAIL PROTECTED] added the comment: Done in r64751. -- nosy: +benjamin.peterson resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3295 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3296] print function not executed in python 3.0 tutorial
Benjamin Peterson [EMAIL PROTECTED] added the comment: Thanks! Fixed in r64752. -- nosy: +benjamin.peterson resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3296 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2862] cleanup of freelist management
Gregory P. Smith [EMAIL PROTECTED] added the comment: committed to 2.6 trunk in r64753. -- resolution: - accepted status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2862 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2632] performance problem in socket._fileobject.read
Gregory P. Smith [EMAIL PROTECTED] added the comment: committed to release25-maint in r64754. -- resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2632 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2620] Multiple buffer overflows in unicode processing
Changes by Gregory P. Smith [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file10027/issue2620-gps01-patch.txt ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2620 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
