[issue11647] function decorated with a context manager can only be invoked once

Nick Coghlan added the comment: I'm prototyping a public version of the recreation API as "ContextDecorator.refresh_cm()" in contextlib2: http://contextlib2.readthedocs.org/en/latest/index.html#contextlib2.ContextDecorator.refresh_cm -- type: behavior -> enhancement _

[issue13586] IDLE: Replace selected not working/consistent with find

Changes by Roger Serwy : Added file: http://bugs.python.org/file24016/find_keep_open.patch ___ Python tracker ___ ___ Python-bugs-list mailing

[issue13586] IDLE: Replace selected not working/consistent with find

Marco Scataglini added the comment: To follow on Terry thought, I think find dialog box should stay open when 'Find' button is pressed, since there is a 'close' button to close it. That would also be a more accepted behavior similar to all the other editors I know. And on silly UI design note

[issue13506] IDLE sys.path does not contain Current Working Directory

Marco Scataglini added the comment: I test Roger patch on 2.7.2.1 and 3.2.1.1 fresh installs on Win7 Pro 32bit and I confirm it is fixing the issue and it also keeps the existing correct behavior. - Note: - I had to apply the patch with GNU patch: Tortoise is not patching my local fi

[issue13586] IDLE: Replace selected not working/consistent with find

Terry J. Reedy added the comment: I am running 3.2.2 on 64-bit Win7Pro, which should not make a difference. So why did ^H work right for me yesterday and not for Marco today. Retrying with fresh IDLEs I discovered the following: selections do not initially appear in the find part of a Replace

[issue13586] IDLE: Replace selected not working/consistent with find

Marco Scataglini added the comment: To check on 3.2 I installed a fresh Python 3.2.1.1 on Win7 x86 32bit and it has the same problem. So this issues is valid on 2.7.2.1 and 3.2.1.1 I --dry-run Roger patch on both 2.7 and 3.2 with no errors or warnings messages and after patching it fixes the i

[issue13522] Document error return values for PyFloat_* and PyComplex_*

Changes by STINNER Victor : -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue13522] Document error return values for PyFloat_* and PyComplex_*

Roundup Robot added the comment: New changeset 67a4e8fe650e by Victor Stinner in branch 'default': Issue #13522: Fix _Py_co_pow() documentation http://hg.python.org/cpython/rev/67a4e8fe650e -- ___ Python tracker _

[issue13522] Document error return values for PyFloat_* and PyComplex_*

Arnaud Calmettes added the comment: Previous patch was also wrong, sorry! -- keywords: +patch Added file: http://bugs.python.org/file24015/complex.rst-2.patch ___ Python tracker ___

[issue13621] Unicode performance regression in python3.3 vs python3.2

STINNER Victor added the comment: > I also noticed a difference between Python 3.2 and 3.3, > but Python 3.3 is 13% *faster* (and not slower). Oops, I misused the timeit module, there is a regression. > New changeset c802bfc8acfc by Victor Stinner in branch 'default': > Issue #13621: Optimize

[issue13621] Unicode performance regression in python3.3 vs python3.2

Roundup Robot added the comment: New changeset c802bfc8acfc by Victor Stinner in branch 'default': Issue #13621: Optimize str.replace(char1, char2) http://hg.python.org/cpython/rev/c802bfc8acfc -- nosy: +python-dev ___ Python tracker

[issue13522] Document error return values for PyFloat_* and PyComplex_*

Arnaud Calmettes added the comment: Fixed. -- Added file: http://bugs.python.org/file24014/diff_complex_rst ___ Python tracker ___ __

[issue13621] Unicode performance regression in python3.3 vs python3.2

STINNER Victor added the comment: > "...text.with.2000.lines...replace("\n", " ") (*10): -37.668161% I also noticed a difference between Python 3.2 and 3.3, but Python 3.3 is 13% *faster* (and not slower). This benchmark is not really representative because stringbench only tests .replace() w

[issue13522] Document error return values for PyFloat_* and PyComplex_*

STINNER Victor added the comment: _Py_c_pow() doc is wrong: + If :attr:`exp.imag` is not null, or :attr:`exp.real` is negative, + this method returns zero and sets :c:data:`errno` to :c:data:`EDOM`. The function only fails if num=0 and exp.real < 0 or if num=0 and exp.imag != 0. -

[issue13522] Document error return values for PyFloat_* and PyComplex_*

Antoine Pitrou added the comment: Committed now. Thank you for the patch! -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker __

[issue13623] Bytes performance regression in python3.3 vs python3.2

STINNER Victor added the comment: I checked stringbench: there is no more performance regression (difference of more than 20%). -- resolution: -> fixed status: open -> closed ___ Python tracker _

[issue13522] Document error return values for PyFloat_* and PyComplex_*

Roundup Robot added the comment: New changeset 68cbf6551710 by Antoine Pitrou in branch '3.2': Issue #13522: document error return values of some float and complex C API functions. http://hg.python.org/cpython/rev/68cbf6551710 New changeset 1f096611baf4 by Antoine Pitrou in branch 'default': I

[issue12170] index() and count() methods of bytes and bytearray should accept byte ints

STINNER Victor added the comment: New changeset 75648db1b3f3 by Victor Stinner in branch 'default': http://hg.python.org/cpython/rev/75648db1b3f3 Issue #13623: Fix a performance regression introduced by issue #12170 in bytes.find() and handle correctly OverflowError (raise the same ValueError t

[issue12170] index() and count() methods of bytes and bytearray should accept byte ints

Roundup Robot added the comment: New changeset 75648db1b3f3 by Victor Stinner in branch 'default': Issue #13623: Fix a performance regression introduced by issue #12170 in http://hg.python.org/cpython/rev/75648db1b3f3 -- ___ Python tracker

[issue13623] Bytes performance regression in python3.3 vs python3.2

Roundup Robot added the comment: New changeset 75648db1b3f3 by Victor Stinner in branch 'default': Issue #13623: Fix a performance regression introduced by issue #12170 in http://hg.python.org/cpython/rev/75648db1b3f3 -- nosy: +python-dev ___ Python

[issue13623] Bytes performance regression in python3.3 vs python3.2

Changes by STINNER Victor : Added file: http://bugs.python.org/file24013/bytes_find-2.patch ___ Python tracker ___ ___ Python-bugs-list mailin

[issue13623] Bytes performance regression in python3.3 vs python3.2

Changes by STINNER Victor : Removed file: http://bugs.python.org/file24012/bytes_find-2.patch ___ Python tracker ___ ___ Python-bugs-list mail

[issue13623] Bytes performance regression in python3.3 vs python3.2

STINNER Victor added the comment: bytes_find.patch only works for Python int, not object with the __index__ method. My new patch (bytes_find-2.patch) uses PyNumber_Check() instead of PyLong_Check() to be more generic. It fixes also a different issue: raise the same ValueError than bytes.find(

[issue10805] traceback.print_exception throws AttributeError when exception is None

Boris FELD added the comment: I add a test to test_traceback.py for this bug. Bug is confirmed on python 3.2 and python3.3. I use 2.x behavior as reference. I don't know if we should add an assertion in traceback.print_exception or traceback._iter_chain, so I add the test for traceback.print_

[issue13623] Bytes performance regression in python3.3 vs python3.2

STINNER Victor added the comment: > (b"A"*1000).find(b"A"): -70% This one is a performance regression introduced by #12170. Attached patch checks object type before trying a conversion to size_t instead of catching an exception. -- keywords: +patch Added file: http://bugs.python.

[issue13522] Document error return values for PyFloat_* and PyComplex_*

Arnaud Calmettes added the comment: I fixed the typo and the markup. -- Added file: http://bugs.python.org/file24009/patch ___ Python tracker ___ ___

[issue13522] Document error return values for PyFloat_* and PyComplex_*

Antoine Pitrou added the comment: There's a typo in the patch: it's PyErr_Occurred (two r's), not PyErr_Occured. Otherwise, looks good to me. -- stage: needs patch -> patch review ___ Python tracker __

[issue13555] cPickle MemoryError when loading large file (while pickle works)

Charles-François Natali added the comment: New version. -- Added file: http://bugs.python.org/file24008/pickle_overflow-1.diff ___ Python tracker ___ ___

[issue13522] Document error return values for PyFloat_* and PyComplex_*

Arnaud Calmettes added the comment: Hi, Here is the patch I propose for this issue. This is my first attempt to contribute to Python, so please don't hit me too hard if I did something wrong. :) When browsing the source code of complexobject.c, I also noticed that the return values of the _

[issue13555] cPickle MemoryError when loading large file (while pickle works)

Antoine Pitrou added the comment: I think there's a problem here: +self->data = realloc(self->data, self->size * sizeof(PyObject *)); +if (self->data == NULL) goto nomemory; If realloc() fails, the old data pointer is lost and therefore will never get free()ed. Same for: +

[issue11231] bytes() constructor is not correctly documented

Roundup Robot added the comment: New changeset beac7d6c7be4 by Victor Stinner in branch '3.2': Issue #11231: Fix bytes and bytearray docstrings http://hg.python.org/cpython/rev/beac7d6c7be4 New changeset dc670add1e28 by Victor Stinner in branch 'default': Issue #11231: Fix bytes and bytearray d

[issue13530] Docs for os.lseek neglect to mention what it returns

STINNER Victor added the comment: Thanks for the patch Jérémy. -- nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue13555] cPickle MemoryError when loading large file (while pickle works)

Charles-François Natali added the comment: Here's a patch which should fix this. However, I'm unable to test it. -- keywords: +patch Added file: http://bugs.python.org/file24006/pickle_overflow.diff ___ Python tracker

[issue13530] Docs for os.lseek neglect to mention what it returns

Roundup Robot added the comment: New changeset 46c418d8a480 by Victor Stinner in branch '3.2': Issue #13530: Document os.lseek() result http://hg.python.org/cpython/rev/46c418d8a480 New changeset b05caa600c40 by Victor Stinner in branch 'default': Issue #13530: Document os.lseek() result http:/

[issue13530] Docs for os.lseek neglect to mention what it returns

Changes by STINNER Victor : -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue5492] Error on leaving IDLE with quit() or exit() under Linux

Boris FELD added the comment: The problem still exists in trunk with 3.2 and 3.3. -- nosy: +Boris.FELD versions: +Python 3.2, Python 3.3 ___ Python tracker ___ __

[issue10951] gcc 4.6 warnings

Roundup Robot added the comment: New changeset d7862e855274 by Victor Stinner in branch '3.2': Issue #10951: Fix a compiler warning in timemodule.c http://hg.python.org/cpython/rev/d7862e855274 New changeset 49b85dba251d by Victor Stinner in branch 'default': Issue #10951: Fix compiler warnings

[issue13624] UTF-8 encoder performance regression in python3.3

STINNER Victor added the comment: > 8x faster (!) for a string of 50.000 ASCII characters Oooh, it's just faster because encoding ASCII to UTF-8 is now O(1). The ASCII data is shared with the UTF-8 data thanks to the PEP 393! -- ___ Python tracker

[issue13624] UTF-8 encoder performance regression in python3.3

STINNER Victor added the comment: Python 3.2 (narrow): ASCII: 1 loops, best of 3: 28.2 usec per loop UCS-1: 1 loops, best of 3: 59.1 usec per loop UCS-2: 1 loops, best of 3: 88.8 usec per loop UCS-4: 1000 loops, best of 3: 254 usec per loop Python 3.2 (wide): ASCII: 1 loops, b

[issue13610] On Python parsing numbers.

Ezio Melotti added the comment: I'll close this then. -- resolution: -> wont fix stage: -> committed/rejected status: open -> closed ___ Python tracker ___ ___

[issue13624] UTF-8 encoder performance regression in python3.3

Changes by Florent Xicluna : -- nosy: +flox ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue13624] UTF-8 encoder performance regression in python3.3

STINNER Victor added the comment: Oh, Antoine told me that I missed the -s command line argument to timeit: $ cat bench.sh echo -n "ASCII: " ./python -m timeit -s 'x="A"*5' 'x.encode("utf-8")' echo -n "UCS-1: " ./python -m timeit -s 'x="\xe9"*5' 'x.encode("utf-8")' echo -n "UCS-2: " ./

[issue13624] UTF-8 encoder performance regression in python3.3

STINNER Victor added the comment: > Can you please provide your exact testing procedure? Here you have. $ cat bench.sh echo -n "ASCII: " ./python -m timeit 'x="A"*5' 'x.encode("utf-8")' echo -n "UCS-1: " ./python -m timeit 'x="\xe9"*5' 'x.encode("utf-8")' echo -n "UCS-2: " ./python -m

[issue13610] On Python parsing numbers.

Jean-Michel Fauth added the comment: > Ezio Melotti Good catch. I'm not complaining. I just find funny to see the number of editors not "colorizing" this kind of Python valid expressions. (IDLE included) For me, subject close. -- ___ Python tracker

[issue13610] On Python parsing numbers.

Raymond Hettinger added the comment: -1 I'm with Mark, Georg, and Benjamin on this one. -- nosy: +rhettinger ___ Python tracker ___ _

[issue13624] UTF-8 encoder performance regression in python3.3

Martin v. Löwis added the comment: Can you please provide your exact testing procedure? Standard iobench.py doesn't support testing for separate ASCII, UCS-1 and UCS-2 data, so you must have used some other tool. Exact code, command line parameters, hardware description and timing results wou

[issue8231] Unable to run IDLE without write-access to config directory

Changes by Roger Serwy : -- components: +IDLE -Library (Lib), Windows nosy: +serwy versions: +Python 2.7, Python 3.2, Python 3.3 -Python 3.1 ___ Python tracker ___ ___

[issue10951] gcc 4.6 warnings

Jérémy Anger added the comment: I've fixed two more warnings, see my patch. (gcc 4.6.2) -- nosy: +kidanger Added file: http://bugs.python.org/file24004/fix_2warnings.diff ___ Python tracker ___

[issue13586] IDLE: Replace selected not working/consistent with find

Roger Serwy added the comment: On Linux using 2.7.1 and 3.2, the Replace dialog does not contain the selected text in the Find field. The find functionality that copies the selected text was introduced in 868ff0dfabd2 on 2002-11-06. Unfortunately it wasn't added to the Replace Dialog code. T

[issue13621] Unicode performance regression in python3.3 vs python3.2

Antoine Pitrou added the comment: Just a note: performance reports shouldn't be assigned to the "benchmarks" category, except if the problem is in the benchmarks themselves. -- assignee: collinwinter -> components: +Interpreter Core -Benchmarks versions: -Python 3.2

[issue13623] Bytes performance regression in python3.3 vs python3.2

Changes by Ezio Melotti : -- nosy: +ezio.melotti ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue13621] Unicode performance regression in python3.3 vs python3.2

Changes by Ezio Melotti : -- assignee: -> collinwinter components: +Unicode nosy: +ezio.melotti ___ Python tracker ___ ___ Python-bug

[issue13624] UTF-8 encoder performance regression in python3.3

Changes by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue13621] Unicode performance regression in python3.3 vs python3.2

Changes by STINNER Victor : -- nosy: +flox ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue13623] Bytes performance regression in python3.3 vs python3.2

Changes by STINNER Victor : -- nosy: +flox ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue13624] UTF-8 encoder performance regression in python3.3

New submission from STINNER Victor : iobench benchmarking tool showed that the UTF-8 encoder is slower in Python 3.3 than Python 3.2. The performance depends on the characters of the input string: * 8x faster (!) for a string of 50.000 ASCII characters * 1.5x slower for a string of 50.000 UCS

[issue13621] Unicode performance regression in python3.3 vs python3.2

STINNER Victor added the comment: See also the issue #13623 for results on bytes. -- ___ Python tracker ___ ___ Python-bugs-list mail

[issue13623] Bytes performance regression in python3.3 vs python3.2

STINNER Victor added the comment: See also the issue #13621 for results on Unicode. -- ___ Python tracker ___ ___ Python-bugs-list ma

[issue13622] Bytes performance regression in python3.3 vs python3.2

Changes by STINNER Victor : -- resolution: -> invalid status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue13622] Bytes performance regression in python3.3 vs python3.2

STINNER Victor added the comment: Boris.FELD told me that there was a bug in compare.py: all numbers are related to Unicode (see #13621), not bytes. -- ___ Python tracker ___ _

[issue13623] Bytes performance regression in python3.3 vs python3.2

STINNER Victor added the comment: Grouped results. find (first): - (b"A"*1000).find(b"A"): -70% - (b"A"*1000).rfind(b"A") : -70% - (b"A"*1000).index(b"A") : -71% - (b"A"*1000).rindex(b"A") : -68% - (b"AB"*1000).index(b"AB") : -68% - (b"AB"*1000).rindex(b"AB"): -67% - (b"AB"*1000).fin

[issue13616] Never ending loop in in update_refs Modules/gcmodule.c

Jesús Cea Avión added the comment: The only way of this thing actually happening is if the GC link list has actually a cycle. Without a testcase to try to reproduce, it can't be debugged. David, can you reproduce this consistently, even if it takes a few hours?. As Amaury pointed out, if you

[issue13623] Bytes performance regression in python3.3 vs python3.2

Changes by Boris FELD : Added file: http://bugs.python.org/file24002/stringbench_log_cpython3.3 ___ Python tracker ___ ___ Python-bugs-list ma

[issue13623] Bytes performance regression in python3.3 vs python3.2

Changes by Boris FELD : Removed file: http://bugs.python.org/file24000/iobench_log_python3.3 ___ Python tracker ___ ___ Python-bugs-list maili

[issue13623] Bytes performance regression in python3.3 vs python3.2

Changes by Boris FELD : Added file: http://bugs.python.org/file24001/compare.py ___ Python tracker ___ ___ Python-bugs-list mailing list Unsub

[issue13623] Bytes performance regression in python3.3 vs python3.2

Changes by Boris FELD : Added file: http://bugs.python.org/file24000/iobench_log_python3.3 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue13623] Bytes performance regression in python3.3 vs python3.2

New submission from Boris FELD : Hello everyone, I juste tried to launch the stringbench on python3.2 and python3.3 dev versions and some bytes tests run slower in python3.3 than in python3.2. I cc the two raw output of both runs. I also extracted most interesting data (all the tests with mor

[issue13621] Unicode performance regression in python3.3 vs python3.2

Boris FELD added the comment: Forgot to describe my environment: Mac OS X 10.6.8 GCC i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3) CPython3.3 revision ea421c534305 CPython3.2 revision 0b86da9d6964 -- ___ Python tracker

[issue13622] Bytes performance regression in python3.3 vs python3.2

Boris FELD added the comment: Forgot to describe my environment: Mac OS X 10.6.8 GCC i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3) CPython3.3 revision ea421c534305 CPython3.2 revision 0b86da9d6964 -- ___ Python tracker

[issue13561] os.listdir documentation should mention surrogateescape

misdre added the comment: Added a small patch to mention surrogateescape and PEP 383. -- keywords: +patch nosy: +misdre Added file: http://bugs.python.org/file23998/listdir-pep383.patch ___ Python tracker

[issue13622] Bytes performance regression in python3.3 vs python3.2

STINNER Victor added the comment: Sorted and grouped results. "replace", "find" and "concat" should be easy to fix, "strip" and "split" depend on "find" performance. replace: - b"...text.with.2000.lines...replace(b"\n", b" ") (*10): -37.668161% find: - (b"A"*1000).find(b"B") (*1000): -30.3

[issue13621] Unicode performance regression in python3.3 vs python3.2

STINNER Victor added the comment: Sorted and grouped results. "replace", "find" and "concat" should be easy to fix, "format" is a little bit more complex, "strip" and "split" depends on "find" performance and require to scan the substring to ensure that the result is canonical (except if inpu

[issue13622] Bytes performance regression in python3.3 vs python3.2

Changes by Boris FELD : Added file: http://bugs.python.org/file23997/compare.py ___ Python tracker ___ ___ Python-bugs-list mailing list Unsub

[issue13622] Bytes performance regression in python3.3 vs python3.2

Changes by Boris FELD : Added file: http://bugs.python.org/file23996/stringbench_log_cpython3.3 ___ Python tracker ___ ___ Python-bugs-list ma

[issue13622] Bytes performance regression in python3.3 vs python3.2

New submission from Boris FELD : Hello everyone, I juste tried to launch the stringbench on python3.2 and python3.3 dev versions and some bytes tests run slower in python3.3 than in python3.2. I cc the two raw output of both runs. I also extracted most interesting data (all the tests with mor

[issue13621] Unicode performance regression in python3.3 vs python3.2

Changes by Boris FELD : Added file: http://bugs.python.org/file23994/compare.py ___ Python tracker ___ ___ Python-bugs-list mailing list Unsub

[issue13621] Unicode performance regression in python3.3 vs python3.2

Changes by Boris FELD : Removed file: http://bugs.python.org/file23993/stringbench.py ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue13621] Unicode performance regression in python3.3 vs python3.2

Changes by Antoine Pitrou : -- nosy: +haypo, pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue13621] Unicode performance regression in python3.3 vs python3.2

Martin v. Löwis added the comment: Thanks, this is a known issue. I'm not too worried, since they are fairly artificial. In the cases I've looked at, I don't think anything can be done about that. -- nosy: +loewis ___ Python tracker

[issue13621] Unicode performance regression in python3.3 vs python3.2

Changes by Antoine Pitrou : -- assignee: collinwinter -> ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:

[issue13621] Unicode performance regression in python3.3 vs python3.2

Changes by Boris FELD : Added file: http://bugs.python.org/file23993/stringbench.py ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue13621] Unicode performance regression in python3.3 vs python3.2

Changes by Boris FELD : Added file: http://bugs.python.org/file23992/stringbench_log_cpython3.3 ___ Python tracker ___ ___ Python-bugs-list ma

[issue13621] Unicode performance regression in python3.3 vs python3.2

New submission from Boris FELD : Hello everyone, I juste tried to launch the stringbench on python3.2 and python3.3 dev versions and some unicode tests run slower in python3.3 than in python3.2. I cc the two raw output of both runs. I also extracted most interesting data (all the tests with m

[issue13610] On Python parsing numbers.

Ezio Melotti added the comment: >>> 999if 888else 888 File "", line 1 999if 888else 888 ^ SyntaxError: invalid token This might be because 888e5 is a valid expression, so the 'e' is parsed as part of the number rather than a separate token. >>> 999 if 888.else 888 File ""

[issue11231] bytes() constructor is not correctly documented

Changes by brendel : Added file: http://bugs.python.org/file23990/patch ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue11231] bytes() constructor is not correctly documented

Changes by brendel : Removed file: http://bugs.python.org/file23989/patch ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe

[issue13619] Add a new codec: "locale", the current locale encoding

STINNER Victor added the comment: I tested locale_encoding-2.patch on Linux, FreeBSD and Windows: UTF-8 and ISO-8859-1 locales on Linux and FreeBSD, and the cp1252 ANSI code page on Windows. -- ___ Python tracker

[issue11231] bytes() constructor is not correctly documented

brendel added the comment: Here is a patch for the docstring of bytes and bytesarray. -- nosy: +brendel Added file: http://bugs.python.org/file23989/patch ___ Python tracker ___

[issue13610] On Python parsing numbers.

Changes by Antoine Pitrou : -- nosy: +gvanrossum versions: +Python 3.3 -Python 3.4 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue13610] On Python parsing numbers.

Jean-Michel Fauth added the comment: I have done a little bit hd/files archeology and found some of my comments. Pointing on number litterals is probably wrong. The fact is that, this happens with practically any expression. And strangely, not all keywords (constructs?) are affected. >>> 999i

[issue13530] Docs for os.lseek neglect to mention what it returns

Changes by Antoine Pitrou : -- stage: -> patch review type: -> behavior versions: +Python 3.3 ___ Python tracker ___ ___ Python-bugs

[issue13555] cPickle MemoryError when loading large file (while pickle works)

Antoine Pitrou added the comment: Ah, I see. It's a bit of a pity not to be able to load files > 1GB, especially on a 64-bit build (!). Perhaps cPickle could be made partly 64-bit compatible? Or at least, indeed, do a proper anti-overflow check. -- ___

[issue13530] Docs for os.lseek neglect to mention what it returns

Jérémy Anger added the comment: Here is a patch which add the return value of lseek into the documentation. -- nosy: +kidanger Added file: http://bugs.python.org/file23988/patch ___ Python tracker

[issue13555] cPickle MemoryError when loading large file (while pickle works)

STINNER Victor added the comment: > Should we fix this (Py_ssize_t, overflow check before computation), as in > #11564? Yes. Use Py_ssize_t type for the buf_size attribute, and replace "bigger <= 0" (test if an overflow occurred) by "self->buf_size > (PY_SSIZE_T_MAX >> 1)". -- nosy:

[issue13555] cPickle MemoryError when loading large file (while pickle works)

Charles-François Natali added the comment: > So it seems unlikely to be the explanation. Victor reproduced in on IRC, and it's indeed an overflow. The problematic code is in readline_file: """ bigger = self->buf_size << 1; if (bigger <= 0) { /* overflow */

[issue13619] Add a new codec: "locale", the current locale encoding

Changes by Ezio Melotti : -- components: +Unicode nosy: +ezio.melotti, lemburg stage: -> patch review type: -> enhancement ___ Python tracker ___ __

[issue13610] On Python parsing numbers.

Georg Brandl added the comment: I don't see a good reason to change this. -- nosy: +georg.brandl ___ Python tracker ___ ___ Python-bu

[issue13619] Add a new codec: "locale", the current locale encoding

STINNER Victor added the comment: Patch version 2: improve the test. Try also the user locale encoding if the C locale uses ISO-8859-1 (should improve the code coverage on FreeBSD, Mac OS X and Solaris). -- Added file: http://bugs.python.org/file23987/locale_encoding-2.patch

[issue11231] bytes() constructor is not correctly documented

STINNER Victor added the comment: Oooh, I missed the important sentence "Accordingly, constructor arguments are interpreted as for bytearray()." The 5 constructors are documented in bytearray doc: http://docs.python.org/dev/library/functions.html#bytearray -- resolution: -> works fo

[issue13453] Tests and network timeouts

STINNER Victor added the comment: http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%203.x/builds/1327/steps/test/logs/stdio == ERROR: test_list_active (test.test_nntplib.NetworkedNNTPTests) --

  1   2   >