[issue7528] Provide PyLong_AsLongAndOverflow compatibility to Python 2.x

Case Van Horsen added the comment: I uploaded a new consolidated diff that includes the original patch with (hopefully) correct whitespace, some tests, and doc updates. The test just verifies that overflow is set/cleared properly. Proper conversions to long are already tested in test_capi. Let

[issue7540] urllib2 request does not update content length after new add_data

Changes by Senthil Kumaran : -- assignee: -> orsenthil nosy: +orsenthil ___ Python tracker ___ ___ Python-bugs-list mailing list Unsub

[issue7539] unicode exceptions terminate pdb.pm() loop

Marius Gedminas added the comment: I don't know what I was smoking when I said pdb.set_trace() wasn't affected; I just reproduced the bug with Python 2.6.4 (r264:75706, Dec 7 2009, 18:45:15) [GCC 4.4.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> imp

[issue7462] Implement fastsearch algorithm for rfind/rindex

Florent Xicluna added the comment: Need additional patch for rpartition and rsplit on string, unicode and bytearray objects. -- stage: patch review -> needs patch ___ Python tracker

[issue7552] uploading fails on long passwords

Tarek Ziadé added the comment: done in r76952, r76953, r76954 and r76955 Thanks magcius ! -- status: open -> closed ___ Python tracker ___ __

[issue7462] Implement fastsearch algorithm for rfind/rindex

Changes by Florent Xicluna : Removed file: http://bugs.python.org/file15636/bench_rfind_algorithms.diff ___ Python tracker ___ ___ Python-bugs-

[issue7462] Implement fastsearch algorithm for rfind/rindex

Florent Xicluna added the comment: Updated benchmarks. strunicode (ms) (ms) == late match, 100 characters s="ABC"*33; ("E"+s+("D"+s)*500).rfind("E"+s) 32.89 15.65 rfind (classic) 32.81 15.63 rindex (classic) 11.77 13.27 rfind (fastsearch) 11.78 13

[issue7462] Implement fastsearch algorithm for rfind/rindex

Changes by Florent Xicluna : Removed file: http://bugs.python.org/file15635/stringbench_rfind.diff ___ Python tracker ___ ___ Python-bugs-list

[issue7462] Implement fastsearch algorithm for rfind/rindex

Florent Xicluna added the comment: There's a typo in the patch for stringbench. Updated patch (with rindex tests, too). -- Added file: http://bugs.python.org/file15637/stringbench_rfind_rindex.diff ___ Python tracker

[issue7462] Implement fastsearch algorithm for rfind/rindex

Changes by Florent Xicluna : Added file: http://bugs.python.org/file15636/bench_rfind_algorithms.diff ___ Python tracker ___ ___ Python-bugs-li

[issue7462] Implement fastsearch algorithm for rfind/rindex

Florent Xicluna added the comment: Bench results show the benefit. And attached patch for stringbench tool. -- Added file: http://bugs.python.org/file15635/stringbench_rfind.diff ___ Python tracker ___

[issue7462] Implement fastsearch algorithm for rfind/rindex

Florent Xicluna added the comment: Additional test cases for rfind. -- Added file: http://bugs.python.org/file15634/issue7462_string_tests.diff ___ Python tracker ___ ___

[issue7554] Some tests in test_cmath use rAssertAlmostEqual incorrectly

Mark Dickinson added the comment: Applied the test_cmath part of the patch in r76948 (trunk) and r76950 (py3k). I was too lazy to backport to the maintenance releases, mostly because that would have involved replacing all the '{}'s in format strings with numbered versions. ('{0}' ...) Thank

[issue7554] Some tests in test_cmath use rAssertAlmostEqual incorrectly

Mark Dickinson added the comment: test_math changes applied in r76945 (trunk), and backported to release26- maint in r76946 for good measure. For the sake of ease of maintenance, I used code that matched the existing py3k code, rather than the exact code Florent provided. -- ___

[issue7554] Some tests in test_cmath use rAssertAlmostEqual incorrectly

Mark Dickinson added the comment: Whoops; I didn't see your patch until too late. -- assignee: -> mark.dickinson resolution: fixed -> status: closed -> open ___ Python tracker ___

[issue7554] Some tests in test_cmath use rAssertAlmostEqual incorrectly

Mark Dickinson added the comment: Thanks! Fixed in r76941 (trunk) and r76942 (release26-maint) (with tweaks in the following two revisions). -- nosy: +mark.dickinson resolution: -> fixed status: open -> closed ___ Python tracker

[issue7554] Some tests in test_cmath use rAssertAlmostEqual incorrectly

Florent Xicluna added the comment: I've done a review of this test file, and removed code duplication between function "almostEqualF" and method "rAssertAlmostEqual". (and changed some syntax to make "-3" happy) -- keywords: +patch Added file: http://bugs.python.org/file15633/issue7554

[issue7554] Some tests in test_cmath use rAssertAlmostEqual incorrectly

Changes by Florent Xicluna : -- title: Some tests in test_cmath should use rAssertAlmostEqual incorrectly -> Some tests in test_cmath use rAssertAlmostEqual incorrectly ___ Python tracker __

[issue7554] Some tests in test_cmath should use rAssertAlmostEqual incorrectly

New submission from Florent Xicluna : These tests do not pass the right arguments to rAssertAlmostEqual. They should use assertAlmostEqual instead. (around line 123) self.rAssertAlmostEqual(cmath.pi, pi_expected, 9, "cmath.pi is %s; should be %s" % (cmath.pi, pi_expected))

[issue6108] unicode(exception) and str(exception) should return the same message on Py2.6

Ezio Melotti added the comment: I created a comprehensive set of tests to check all the possibilities that I listed in msg96319 and updated the patch for Object/exceptions.c. Without patch all the test_*_with_overridden__str__ and test_builtin_exceptions fail, both on 2.6 and on trunk, with the

[issue7553] test_long_future is faulty

Florent Xicluna added the comment: Let me show the issue: ~ $ cat bar.py def apply_(func, args=(), kw={}): return func(*args, **kw) ~ $ cat foo.py from __future__ import division import bar def test(): assert eval('1/2') == .5 assert apply(eval, ('1/2',)) == .5 # This test yi

[issue7553] test_long_future is faulty

Benjamin Peterson added the comment: eval() inherits the flags of the module it is used in. -- nosy: +benjamin.peterson resolution: -> works for me status: open -> closed ___ Python tracker ___

[issue7553] test_long_future is faulty

Florent Xicluna added the comment: Removed 2.6 from the todolist. Not worth the effort. "with self.assertRaises(...):" construct is not supported in 2.6. -- versions: -Python 2.6 ___ Python tracker __

[issue7551] SystemError/MemoryError/OverflowErrors on encode() a unicode string

Martin v. Löwis added the comment: Just to support Mark's decision: Python 2.4 is no longer maintained; you are on your own with any problems you encounter with it. So closing it as "won't fix" would also have been appropriate. The same holds for 2.5, unless you can demonstrate this to cause se

[issue7553] test_long_future is faulty

Changes by Florent Xicluna : -- stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://m

[issue7552] uploading fails on long passwords

JP St. Pierre added the comment: This patch should fix the bug. -- keywords: +patch Added file: http://bugs.python.org/file15631/auth_7552.patch ___ Python tracker ___ __

[issue7553] test_long_future is faulty

Florent Xicluna added the comment: Patch which fixes the tests: call the "eval" in the module. -- keywords: +patch Added file: http://bugs.python.org/file15630/issue7553_test_long_future.diff ___ Python tracker ___

[issue7553] test_long_future is faulty

New submission from Florent Xicluna : This test do not test "true division" contrary to what is claimed. for zero in ["huge / 0", "huge / 0L", "mhuge / 0", "mhuge / 0L"]: self.assertRaises(ZeroDivisionError, eval, zero, namespace) Because it uses the module "unittest" to eval the ex

[issue7552] uploading fails on long passwords

New submission from JP St. Pierre : Uploading a file to PyPI fails when a user has a long password, as base64.encodestring linewraps data. Either replace '\n' with '', or use base64.standard_b64encode -- assignee: tarek components: Distutils messages: 96709 nosy: magcius, tarek severity:

[issue1673007] urllib2 requests history + HEAD support

Éric Araujo added the comment: If you know you want an HEAD request, it means you already know it will be an HTTP request, so why not directly use httplib or httplib2 instead of urllib? Aside: s/sended/sent/ Cheers -- nosy: +Merwok ___ Python track

[issue7092] Test suite emits many DeprecationWarnings when -3 is enabled

Florent Xicluna added the comment: Patch for pprint: when keys are not the same type, "-3" emits warnings. Partial backport from Py3k. -- Added file: http://bugs.python.org/file15629/issue7092_pprint.diff ___ Python tracker

[issue1673007] urllib2 requests history + HEAD support

Ezio Melotti added the comment: +1 for HEAD -- versions: +Python 3.2 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsub

[issue1673007] urllib2 requests history + HEAD support

Senthil Kumaran added the comment: Having a HEAD request for urllib2 might be a good idea. I shall use this patch to add the functionality. But, having a history support in the urllib2 module is not a good idea IMO. It is best left to the clients which might use urllib2. -- __

[issue7092] Test suite emits many DeprecationWarnings when -3 is enabled

Florent Xicluna added the comment: Patch for the compiler package and astgen.py tool. Basically: def __init__(self, (left, right), lineno=None): ==> def __init__(self, leftright, lineno=None): -- Added file: http://bugs.python.org/file15628/issue7092_compiler.diff __

[issue6501] Fatal LookupError: unknown encoding: cp0 on Windows embedded startup.

Antoine Pitrou added the comment: Well, this might prevent the crash but how does the system behave afterwards? Do the standard streams use utf-8 by default? At the minimum, we should still output a warning on stderr. -- ___ Python tracker

[issue7551] SystemError/MemoryError/OverflowErrors on encode() a unicode string

Mark Dickinson added the comment: Well, the signature of PyUnicode_Encode in Python 2.4 (see Objects/unicodeobject.c) is: PyObject *PyUnicode_Encode(const Py_UNICODE *s, int size, const char *encoding, const char

[issue7092] Test suite emits many DeprecationWarnings when -3 is enabled

Florent Xicluna added the comment: Many fixes of modules and packages outside Lib/test Dev notes: * for bsddb and dbhash the warning message should include "module" to be ignored by "test_support.import_module" * patch for mailbox is copied from Lib/cgi.py * other fixes are trivial

[issue7376] "python -m doctest" results in FAIL: Doctest: __main__.DebugRunner

R. David Murray added the comment: The bug doesn't exist on 2.6, so I'm not backporting. Ported to py3k in r76937 and backported to 3.1 in r76938. -- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed versions: -Python 2.6

[issue1286] fileinput, StringIO, and cStringIO do not support the with protocol

Senthil Kumaran added the comment: I reviewed the patches attached. - The patch to add Context Manager support for fileinput.py seems good. It has docs too. This discussion did not conclude on the need for Context Manager for StringIO. With py3k having it, it should be good for py2.7 to provide

[issue7551] SystemError/MemoryError/OverflowErrors on encode() a unicode string

Andreas Jung added the comment: Both systems are Linux system running a narrow Python build. The problem does not occur with Python 2.5 or 2.6. Unfortunately this error occurs with Zope 2 which is tied (at least with versions prior to Zope 2.12 to Python 2.4). -- status: pending -> o

[issue7551] SystemError/MemoryError/OverflowErrors on encode() a unicode string

Mark Dickinson added the comment: Is the first machine also a Linux machine? Perhaps the difference is that the first machine has a wide-unicode build (i.e., it uses UCS4 internally) and the other doesn't? Unfortunately there's not much that the python-devs can do about this unless the prob

[issue7376] "python -m doctest" results in FAIL: Doctest: __main__.DebugRunner

R. David Murray added the comment: I has already adjusted the patch, in a slightly different fashion, but to much the same effect. Checked in to trunk in r76935. -- ___ Python tracker _

[issue7551] SystemError/MemoryError/OverflowErrors on encode() a unicode string

New submission from Andreas Jung : We encountered a pretty bizarre behavior of Python 2.4.6 while decoding a 600MB long unicode string 'data': Python 2.4.6 (8GB RAM, 64 bit) (Pdb) type(data) (Pdb) len(data) 601794657 (Pdb) data2=data.encode('utf-8') *** SystemError: Negative size passed to

[issue7376] "python -m doctest" results in FAIL: Doctest: __main__.DebugRunner

Florent Xicluna added the comment: Variant which gives different usage messages: ~ $ ./python -m doctest usage: doctest [-v] file ... ~ $ ./python Lib/doctest.py usage: Lib/doctest.py [-v] file ... -- Added file: http://bugs.python.org/file15626/issue7376_usage_v2.diff __

[issue7528] Provide PyLong_AsLongAndOverflow compatibility to Python 2.x

Case Van Horsen added the comment: I will work on documentation and test case patches. Per comments on python-dev, there doesn't appear to be interest in distributing forward compatibility files. I will update the bug report with a slightly revised version of py3intcompat.c and just leave it at

[issue5080] PyArg_Parse* should raise TypeError for float parsed with integer format

Mark Dickinson added the comment: 'h' also produces a DeprecationWarning; I just added the missing tests for it in r76930 (trunk) and r76931 (py3k). -- ___ Python tracker ___ _

[issue7351] Documentation typos found in "zipfile — Work with ZIP archives"

Antoine Pitrou added the comment: While the mismatched casing is unfortunate, I don't think changing it for the sake of aesthetics is a good deal given that many existing programs will have to be converted to the new spelling. -- nosy: +pitrou ___ Py

[issue7351] Documentation typos found in "zipfile — Work with ZIP archives"

Éric Araujo added the comment: Your patch need to include an alias (BadZipfile = BadZipFile) to preserve compatibility with old pickles, as explains msg95477. Cheers -- nosy: +Merwok ___ Python tracker ___

[issue5080] PyArg_Parse* should raise TypeError for float parsed with integer format

Mark Dickinson added the comment: Hmm. That's unfortunate: for argument type in 'bBHiIlkKn', an attempt to pass a float results in a DeprecationWarning. For type 'L', there's no DeprecationWarning, and the float is silently truncated. So for type 'L' I guess we still have to go through a

[issue5341] A selection of spelling errors and typos throughout source

Éric Araujo added the comment: Short summary from a discussion on #python-dev: - verb form: “This function is built in.” - adjective form: “``str`` is a built-in function” - noun form (not mainstream English, but usual in programming contexts): “``repr`` is a builtin”, “prefer the builtins”. --

[issue7381] subprocess.check_output: "docstring has inconsistent leading whitespace"

Changes by Florent Xicluna : Added file: http://bugs.python.org/file15625/issue7381_py3k_v3.diff ___ Python tracker ___ ___ Python-bugs-list ma

[issue7381] subprocess.check_output: "docstring has inconsistent leading whitespace"

Florent Xicluna added the comment: Committed to r76925 (trunk) and r76926 (py3k). Thank you Georg. I see small remaining inconsistencies in the docstring. Either we agree with implicit "import subprocess" or "from subprocess import *", but we should not mix both. See additional patches: * is

[issue7376] "python -m doctest" results in FAIL: Doctest: __main__.DebugRunner

R. David Murray added the comment: The patch results in this type of usage message: usage: /home/rdmurray/python/trunk/Lib/doctest.py [-v] file ... which while technically correct isn't the way I called it. It would be better to at least use basename on argv[0]. (I wonder if there's some way

[issue6501] Fatal LookupError: unknown encoding: cp0 on Windows embedded startup.

Florent Xicluna added the comment: Patch to prevent crash when PYTHONIOENCODING is invalid: ~ $ PYTHONIOENCODING= ./python Fatal Python error: Py_Initialize: can't initialize sys standard streams LookupError: unknown encoding: Abandon -- keywords: +patch nosy: +flox versions: +Python

[issue7485] Error in FAQ entry '4.25 Why doesn't Python have a "with" statement for attribute assignments?'

Georg Brandl added the comment: This sentence has already been removed from the version of the FAQ that is now in the source tree: http://docs.python.org/dev/faq/design.html#why-doesn-t-python-have-a-with-statement-for-attribute-assignments -- resolution: -> out of date status: open ->

[issue4380] Deepcopy of functools.partial gives wierd exception

Changes by Florent Xicluna : -- resolution: -> fixed stage: -> committed/rejected status: open -> closed ___ Python tracker ___ ___ P

[issue7376] "python -m doctest" results in FAIL: Doctest: __main__.DebugRunner

Changes by R. David Murray : -- stage: patch review -> commit review ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue7376] "python -m doctest" results in FAIL: Doctest: __main__.DebugRunner

Changes by R. David Murray : -- assignee: -> r.david.murray ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: htt

[issue7493] doc: patch for Doc/faq/design.rst

Georg Brandl added the comment: Thanks, applied in r76923. For future patches, please use notes sparingly, and warnings even more so. Not every sentences starting with "Note that..." needs to be a Note. Also, Notes should contain whole sentences (i.e. the first word is uppercased). -

[issue7033] C/API - Document exceptions

Antoine Pitrou added the comment: One nitpick: Python/errors.c uses tabs for indentation, your patch should as well. -- ___ Python tracker ___ ___

[issue7495] doc: patch for Doc/faq/programming.rst

Georg Brandl added the comment: Thanks, applied in r76920 and r76922. -- status: open -> closed ___ Python tracker ___ ___ Python-bugs

[issue7033] C/API - Document exceptions

R. David Murray added the comment: Yes, I'd say that counts as a brief discussion :) -- ___ Python tracker ___ ___ Python-bugs-list ma

[issue7033] C/API - Document exceptions

Georg Brandl added the comment: Funnily, I already did ask on python-dev, and only got one (+1) answer from Brett. I was going to add it some time when I have more cycles for Python. -- ___ Python tracker

[issue7550] PyLong_As* methods should not call nb_int.

Mark Dickinson added the comment: Just as an experiment, I removed the calls to nb_int and ran the test- suite. The only test failures were in test_ctypes, test_getargs2, and test_math. The test_math failure was from math.factorial depending on PyLong_AsLong to convert floats; I've fixed th

[issue7033] C/API - Document exceptions

R. David Murray added the comment: Also, what about tests? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: h

[issue7033] C/API - Document exceptions

Antoine Pitrou added the comment: > Since it's a new CAPI I think it should probably be discussed briefly on > python-dev. So do I. -- nosy: +pitrou ___ Python tracker ___ _

[issue7033] C/API - Document exceptions

R. David Murray added the comment: Since it's a new CAPI I think it should probably be discussed briefly on python-dev. -- nosy: +r.david.murray priority: -> normal stage: -> patch review ___ Python tracker _

[issue7441] Py3.1: Fatal Python Error: Py_Initialize...unknown encoding: chcp 65001.

Florent Xicluna added the comment: Thank you for your report. See #6501 about the Fatal Error See #6058 for the feature request (cp65001 on windows). -- resolution: -> duplicate stage: -> committed/rejected superseder: -> Fatal LookupError: unknown encoding: cp0 on Windows embedded

[issue7550] PyLong_As* methods should not call nb_int.

Mark Dickinson added the comment: Since PyLong_AsLong goes through PyLong_AsLongAndOverflow, this change would also affect calls to PyLong_AsLong. -- ___ Python tracker ___

[issue7376] "python -m doctest" results in FAIL: Doctest: __main__.DebugRunner

Changes by Florent Xicluna : -- stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://m

[issue7376] "python -m doctest" results in FAIL: Doctest: __main__.DebugRunner

Florent Xicluna added the comment: Minor update: replaced '{}' by '{0}' for compatibility with 2.6. Ready for review and merge. -- Added file: http://bugs.python.org/file15622/issue7376_usage.diff ___ Python tracker

[issue7376] "python -m doctest" results in FAIL: Doctest: __main__.DebugRunner

Changes by Florent Xicluna : Removed file: http://bugs.python.org/file15392/issue7376_usage.diff ___ Python tracker ___ ___ Python-bugs-list ma

[issue7550] PyLong_As* methods should not call nb_int.

New submission from Mark Dickinson : The following C-API functions: PyLong_AsLongAndOverflow PyLong_AsUnsignedLongMask PyLong_AsLongLong PyLong_AsUnsignedLongLongMask call nb_int for inputs that don't satisfy PyLong_Check. They thus accept floats, Decimal instances, etc. They should probably

[issue7528] Provide PyLong_AsLongAndOverflow compatibility to Python 2.x

Mark Dickinson added the comment: The longobject.diff patch looks fine, modulo some whitespace nits. (Older C source files use width-8 tabs for indentation.) Are you interested in adding documentation and tests (the latter in the test_capi module)? One thing about the patch struck me as odd

[issue7549] 2.6.4 Win32 linked to debug DLLs?

John Wells added the comment: Thanks for the quick follow-up. You're right -- given your explanation of what wininst-8_d.exe is, the interesting question now is why it is running. I get two errors every day, in the early hours of the morning. Before I delete this file, I will see if ProcessMon

[issue7033] C/API - Document exceptions

lekma added the comment: Is there any chance that this will make it in? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue7523] add SOCK_NONBLOCK and SOCK_CLOEXEC to socket module

lekma added the comment: this one addresses Antoines's comments (with the help of R. David Murray). -- Added file: http://bugs.python.org/file15621/Issue7523_3.diff ___ Python tracker __

[issue7549] 2.6.4 Win32 linked to debug DLLs?

Martin v. Löwis added the comment: I have now removed these files from my build directory, so they won't get included in future releases. -- resolution: -> fixed status: open -> closed ___ Python tracker _

[issue7549] 2.6.4 Win32 linked to debug DLLs?

Martin v. Löwis added the comment: wininst*.exe is the binary that gets patched into the zip file when you build a windows installer out of your Python package. wininst-8_d.exe is the debug version of that, so it's not surprising that it is linked with the debug CRT. What is really puzzling her