[issue4027] wrong page index number in reference book of python documentation

Winfried Plappert <[EMAIL PROTECTED]> added the comment: This problem also applies to Python 3.0rc1. Georg, could you please comment on ray's and tjreedy's question. Thanks -- versions: +Python 3.0 ___ Python tracker <[EMAIL PROTECTED]>

[issue3704] cookielib doesn't handle URLs with / in parameters

Senthil <[EMAIL PROTECTED]> added the comment: John, issue3647 tries relative url parsing and joins to be RFC3986 compliance. ___ Python tracker <[EMAIL PROTECTED]> ___

[issue4027] wrong page index number in reference book of python documentation

Ray Wang <[EMAIL PROTECTED]> added the comment: > We are all volunteers here, and I see three replies. > This may or may not be trivial to fix, and may take some time. > Python docs are written in rst format and translated by Sphinx to > various formats. The main translation is to html, as view

[issue3924] cookielib chokes on non-integer cookie version, should ignore it instead

John J Lee <[EMAIL PROTECTED]> added the comment: The sensible fix for this is to strip the quotes off, defaulting to version 0 on failure to parse the version cookie-attribute. It's not necessary to retain the original version string. By the way, what you posted warning rather than a strictly

[issue3704] cookielib doesn't handle URLs with / in parameters

John J Lee <[EMAIL PROTECTED]> added the comment: Do we have an RFC 3986 URI parser in the stdlib now? It would be better to use that if so, but I don't see one. Failing that, an implementation of the relevant part of that RFC is only about four lines of code, so that would be better than naive

[issue4131] Note that Firefox 3 does not write cookies.txt

New submission from John J Lee <[EMAIL PROTECTED]>: Just adds a note to the cookielib documentation to point out that Firefox 3 no longer writes cookies.txt, the file format understood by cookielib.MozillaCookieJar (firefox now maintains persistent cookie state in an sqlite database). --

[issue2190] MozillaCookieJar ignore HttpOnly cookies

John J Lee <[EMAIL PROTECTED]> added the comment: I think firefox 3 no longer writes cookies.txt (it writes cookies.sqlite instead). Can anybody point out a version of firefox that wrote this HttpOnly information to cookies.txt, so the patch can be tested? __

[issue4073] distutils build_scripts and install_data commands need 2to3 support

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > If you'd like, I can add support for skipping backup files to 2to3. That would be useful, I think. ___ Python tracker <[EMAIL PROTECTED]> _

[issue4073] distutils build_scripts and install_data commands need 2to3 support

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: If you'd like, I can add support for skipping backup files to 2to3. -- nosy: +benjamin.peterson ___ Python tracker <[EMAIL PROTECTED]>

[issue4049] IDLE does not open at all

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > I am running Windows XP Professional x64 and encountered the same > problem. Everything appeared to go fine on the installation, but then > IDLE just refuses to run, nothing appears in the task manager, no > errors, nothing. Command line st

[issue4043] Warnings in IDLE raise TypeError (such as attempting to import deprecated modules)

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Fixed in r66905. -- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> __

[issue4049] IDLE does not open at all

Chris Ozeroff <[EMAIL PROTECTED]> added the comment: This bug does not just affect Vista. I am running Windows XP Professional x64 and encountered the same problem. Everything appeared to go fine on the installation, but then IDLE just refuses to run, nothing appears in the task manager, no erro

[issue1570255] redirected cookies

John J Lee <[EMAIL PROTECTED]> added the comment: Sorry I turned up rather late here (is there a way to subscribe to changes to all bugs whose comments or title contain a given string?) If it works with Firefox and not with cookielib it's almost certainly a bug. However, it's not clear to me fr

[issue3725] telnetlib module broken by str to unicode conversion

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Fixed in r66904. -- resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue4130] Intel icc 9.1 does not support __int128_t used by ctypes

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: Why are you reporting this as a bug in Python? Isn't it rather a bug in icc? -- nosy: +loewis ___ Python tracker <[EMAIL PROTECTED]>

[issue4130] Intel icc 9.1 does not support __int128_t used by ctypes

New submission from jared jennings <[EMAIL PROTECTED]>: If the Intel 9.1 compilers are used to compile Python 2.6, the following compiler error results: /mnt/gpfs/usrpeople/jenninjl/Python-2.6-intel/Modules/_ctypes/libffi/src/x86/ffi64.c(43): error: identifier "__int128_t" is undefined __int

[issue2007] cookielib lacks FileCookieJar class for Internet Explorer

John J Lee <[EMAIL PROTECTED]> added the comment: Note that the code on wwwsearch.sf.net only reads cookies, and does not write them. Also, the approach used is fragile to changes to MS's "index.dat" database, which was the reason why that code was not included when cookielib was added. As far

[issue3574] compile() cannot decode Latin-1 source encodings

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > I added a test for compile() in there, which is why the patch is > claiming that. There is an uploaded version of test_pep3120.py on the > issue. Ah, ok. I missed that - that change is also fine. ___ Py

[issue4129] C/API documentation: request for documentation of change to Py_ssize_t* arguments.

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: I don't think that we will change the 2.5 manuals anymore; Python 2.5 is about to see its last bug-fix release. For 2.6, I suppose contributions would be welcome. -- nosy: +loewis ___ Python trac

[issue3909] Building PDF documentation from tex files

Sergey Lipnevich <[EMAIL PROTECTED]> added the comment: I don't know what the proper procedure is (reopening or filing a new ticket), but I see this problem with Sphinx 0.5dev-20081015 and Python 2.6 on Windows XP. The change recommended by Winfried in msg73874 seems to fix it (pat

[issue4027] wrong page index number in reference book of python documentation

Terry J. Reedy <[EMAIL PROTECTED]> added the comment: We are all volunteers here, and I see three replies. This may or may not be trivial to fix, and may take some time. Python docs are written in rst format and translated by Sphinx to various formats. The main translation is to html, as viewed

[issue3574] compile() cannot decode Latin-1 source encodings

Brett Cannon <[EMAIL PROTECTED]> added the comment: On Tue, Oct 14, 2008 at 11:05 PM, Martin v. Löwis <[EMAIL PROTECTED]> wrote: > > Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > > The patch looks fine to me, please apply. > Great! > I notice that the diff file reports changes to tes

[issue4043] Warnings in IDLE raise TypeError (such as attempting to import deprecated modules)

Russell Blau <[EMAIL PROTECTED]> added the comment: This error is caused by line 27 in run.py: def idle_formatwarning_subproc(message, category, filename, lineno): needs to be changed to -- def idle_formatwarning_subproc(message, category, filename, lineno, line=None): so that the fu

[issue4126] remove not decodable environment variables

Toshio Kuratomi <[EMAIL PROTECTED]> added the comment: """ About your subprocess example: we choose to refuse it because we don't mix bytes (your non decodable PATH) and unicode ('myapp.sh') """ If python3 is doing things right we shouldn't be mixing bytes and unicode here: 1) the programmer is

[issue4036] Support bytes for subprocess.Popen()

Changes by Toshio Kuratomi <[EMAIL PROTECTED]>: -- nosy: +a.badger ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list maili

[issue3905] subprocess failing in GUI applications on Windows

Weird <[EMAIL PROTECTED]> added the comment: Georg Brandl thank you, i was having the same problem, but now is fixed -- nosy: +Weird ___ Python tracker <[EMAIL PROTECTED]> ___

[issue4129] C/API documentation: request for documentation of change to Py_ssize_t* arguments.

Jakob Schiøtz <[EMAIL PROTECTED]> added the comment: Don't get me wrong: I am not complaining about the code breakage, it is unavoidable as long as Python is a developing language. As you say I can use newer versions of at least some of the modules. I just think it would be nice for developers

[issue4129] C/API documentation: request for documentation of change to Py_ssize_t* arguments.

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: I think the Py_ssize_t change is clearly documented in the "What's new" document: http://docs.python.org/whatsnew/2.5.html#pep-353-using-ssize-t-as-the-index-type This paragraph also links to: http://www.python.org/dev/peps/pep-0353/#doe

[issue4129] C/API documentation: request for documentation of change to Py_ssize_t* arguments.

New submission from Jakob Schiøtz <[EMAIL PROTECTED]>: In general, the Python C/API manual is very careful to document when changes have occurred in the API, this is really useful information when writing portable extension modules to be used with different Python versions. However, there is a g

[issue4128] Performance regression in long division in 2.6

Fredrik Johansson <[EMAIL PROTECTED]> added the comment: > The speed difference comes from different compiler options. I figured as much. I'm using the binaries from python.org (see the .txt file; it includes version headers). The question is why the compilation changes for 2.6 slowed down divi

[issue4128] Performance regression in long division in 2.6

STINNER Victor <[EMAIL PROTECTED]> added the comment: The source code is unchanged except the format functions (binary and octal bases with the new prefixes: 0b, 0o). The speed difference comes from different compiler options. - (Ubuntu Gutsy) python2.5: 1010 ms - python trunk: 1010 ms - pyt

[issue4128] Performance regression in long division in 2.6

New submission from Fredrik Johansson <[EMAIL PROTECTED]>: On my laptop (Windows XP, 32-bit), long division is about 15% slower in 2.6 compared to 2.5. See the attached .txt for timings. I noticed this when comparing the unit tests for mpmath (http://code.google.com/p/mpmath/) under 2.5 and 2.6.

[issue4027] wrong page index number in reference book of python documentation

Ray Wang <[EMAIL PROTECTED]> added the comment: any feedback here? ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mailing list U

[issue4126] remove not decodable environment variables

STINNER Victor <[EMAIL PROTECTED]> added the comment: About your subprocess example: we choose to refuse it because we don't mix bytes (your non decodable PATH) and unicode ('myapp.sh'). Using my patch in issue #4036 you will be able to run program with bytes arguments (including the program n

[issue4073] distutils build_scripts and install_data commands need 2to3 support

Changes by Martin v. Löwis <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file11803/build_scripts.diff ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue4073] distutils build_scripts and install_data commands need 2to3 support

Changes by Martin v. Löwis <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11802/build_scripts.diff ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue4073] distutils build_scripts and install_data commands need 2to3 support

Changes by Martin v. Löwis <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file11802/build_scripts.diff ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue4073] distutils build_scripts and install_data commands need 2to3 support

Changes by Martin v. Löwis <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11801/build_scripts.diff ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue4073] distutils build_scripts and install_data commands need 2to3 support

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: Here is a patch. It refactors the 2to3 support into a function in util, and adds build_scripts support. For build_scripts, the approach is slightly different from the one proposed by Mark: I modify copy_scripts to collect the modified files,