[issue3574] compile() cannot decode Latin-1 source encodings
Martin v. Löwis [EMAIL PROTECTED] added the comment: The patch looks fine to me, please apply. I notice that the diff file reports changes to test_pep3120.py. No such changes should be necessary, so please exclude them from committing. -- assignee: loewis - brett.cannon keywords: -needs review resolution: - accepted ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3574 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue957650] Fix for bugs relating to ntpath.expanduser()
Changes by Martin v. Löwis [EMAIL PROTECTED]: -- assignee: loewis - priority: high - normal resolution: - accepted status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue957650 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3725] telnetlib module broken by str to unicode conversion
Dmitry Vasiliev [EMAIL PROTECTED] added the comment: The patch is good. It's exactly what I told about in msg72132. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3725 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 that occasionally write python modules to have the information at hand in the C/API manual, since that is where they will be looking when writing the module. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4129 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue3905 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4036] Support bytes for subprocess.Popen()
Changes by Toshio Kuratomi [EMAIL PROTECTED]: -- nosy: +a.badger ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4036 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 only sending unicode to subprocess, not a mixture
of bytes and unicode.
2) Python should be converting the arguments to subprocess.call() into
bytes before combining it with PATH, at least on Unix. The conversion
to bytes is something Python has to do at some point before looking on
the filesystem for the command as filenames are a sequence of bytes in Unix.
Note: your patch for #4036 looks like the right thing to do for the args
argument but as you point out, that doesn't have bearing on the environment.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4126
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 division but not e.g. multiplication, and if there is a workaround. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4128 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 group of changes that are not documented. In Python 2.5 the Py_ssize_t type was introduced, and a number of functions had arguments changed from int to Py_ssize_t (a trivial change) or from int* to Py_ssize_t*. The latter is an incompatible change on 64-bit platforms, as int and Py_ssize_t have different size, and this DOES break extension modules on 64-bit platforms. For example, the change in int PySlice_GetIndices breaks the Scientific Python NetCDF module badly. I suggest that a note is added to the documentation of all functions taking a Py_ssize_t* argument stating that the type of the argument was changed in Python 2.5. Best regards Jakob -- assignee: georg.brandl components: Documentation messages: 74801 nosy: georg.brandl, schiotz severity: normal status: open title: C/API documentation: request for documentation of change to Py_ssize_t* arguments. type: feature request versions: Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4129 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 function signature matches that of warnings.formatwarning -- nosy: +russblau ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4043 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 test_pep3120.py. No such changes should be necessary, so please exclude them from committing. 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. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3574 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. It appears that most tests run 10-20% faster under 2.6 (good work all Python developers!), but the tests performing very high precision arithmetic run noticeably slower. From some quick benchmarking, addition and multiplication are not the culprits (they both actually seem to be quite a bit faster in 2.6). There could be other factors involved, but from what I've found out so far, it is only division that has become slower in 2.6. Division in Python 2.4 is also the same speed as 2.5. -- components: Interpreter Core files: division_speed.txt messages: 74798 nosy: fredrikj severity: normal status: open title: Performance regression in long division in 2.6 versions: Python 2.6 Added file: http://bugs.python.org/file11804/division_speed.txt ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4128 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 on the site. Translation to .pdf is indirect via translation to latex and then from latex to .pdf. Since the .html index appears flawless, and since a different .pdf has problems, I suspect that the .pdf index problem is in one of the two translation steps. Hence the change of component. In the meanwhile, either ignore the index or use the html version. -- components: +Documentation tools (Sphinx) -Documentation ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4027 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 (patch attached). The version of MiKTeX: MiKTeX-pdfTeX 2.7.3147 (1.40.9) (MiKTeX 2.7) Copyright (C) 1982 D. E. Knuth, (C) 1996-2006 Han The Thanh TeX is a trademark of the American Mathematical Society. -- keywords: +patch nosy: +sergey Added file: http://bugs.python.org/file11805/sphinx.sty-issue3909.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3909 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue4027 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/#doesn-t-this-break-much-code which happens to mention the incompatibility in the slice API. Didn't you get any compilation warning? I suggest to use a newer version of Scientific Python: 2.7 at least uses Py_ssize_t throughout its code. -- nosy: +amaury.forgeotdarc ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4129 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 - python trunk with -O0: 1800 ms I'm using -O0 to help gdb debug, but the default gcc optimization level for Python is -03. Did you recompiled your own Python or did you use the binary at python.org? Look at the compilater option for python 2.5 and python 2.6. -- nosy: +haypo ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4128 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 tracker [EMAIL PROTECTED] http://bugs.python.org/issue4129 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3574 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 as I know, the index.dat format is not specified and is subject to change or removal by MS. It's possible that that MSIE cookiejar is already broken on Windows Vista, for example, since I have never tested it on that platform. An alternative approach that should allow writing cookies would be to use InternetGetCookie / InternetSetCookie API: http://msdn.microsoft.com/en-us/library/aa384710(VS.85).aspx A *sketch* of that approach (which I'm not going to implement properly) is here: http://codespeak.net/svn/wwwsearch/mechanize/trunk/attic/MSIEDBCookieJar.py The other, fragile (but working, at least on some MS OSes) approach: http://codespeak.net/svn/wwwsearch/mechanize/trunk/mechanize/_msiecookiejar.py -- nosy: +jjlee ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2007 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 __int128_t sse[MAX_SSE_REGS]; ^ Forum thread regarding lack of support for __int128_t in icc: http://software.intel.com/en-us/forums/intel-c-compiler/topic/56652/ Intel C++ Compiler 10.1 for Linux, Intrinsic Reference: http://softwarecommunity.intel.com/isn/downloads/softwareproducts/pdfs/347603.pdf The Intrinsic Reference details (pp. 2-4) the __m128 type supported by the Intel compiler, and restrictions on its use. (Note that the compiler used was 9.1 but the documentation is from 10.1.) -- assignee: theller components: ctypes messages: 74813 nosy: jared.jennings, theller severity: normal status: open title: Intel icc 9.1 does not support __int128_t used by ctypes type: compile error versions: Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4130 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue4130 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue3725 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 from the report what the real bug might be, because cookies aren't really redirected -- they're just added to the new request following the usual rules for adding Cookie: headers to requests. That's why the redirect handler deliberately doesn't add the unredirected headers -- the Cookie header gets added later on, by HTTPCookieProcessor. So, a diagnosis of the problem would involve finding out why cookielib thinks that your cookie should not be returned to the server in the request in question (which just happens to be a redirected request). Running your script with cookielib's logging enabled (see the documentation) will probably be all that's required to find that out; if you can still reproduce this, please post the log here (sanitized to remove usernames, passwords, etc.). If not, a test case, or failing that a sanitized dump of the HTTP traffic, would be very useful. -- nosy: +jjlee ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1570255 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 errors, nothing. Command line still works. When I read Raj's coment, I realized that I had only installed it for me, not for all users. Installing it the other way worked. This seems like a pretty serious bug, because users (like me) are probably going to be totally baffled as to the cause, since there is no feedback. Thanks for the workaround! -- nosy: +scionkiller ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4049 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue4043 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 still works. It's normal that there are no errors. They get to stderr, and there is no stderr in a GUI application. Can you please try these steps, and report results? 1. open cmd.exe 2. cd \python26 3. python.exe Lib\idlelib\idle.py Report any output that this produces. This seems like a pretty serious bug I don't think it's pretty serious. It has a workaround; a pretty serious bug doesn't have one. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4049 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue4073 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue4073 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2190 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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). -- assignee: georg.brandl components: Documentation files: firefox3_cookies_txt.patch keywords: patch messages: 74823 nosy: georg.brandl, jjlee severity: normal status: open title: Note that Firefox 3 does not write cookies.txt Added file: http://bugs.python.org/file11806/firefox3_cookies_txt.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4131 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 naively looking for ? (request_path should probably be changed at the same time). I'll try and add a patch that does that and check what Firefox does to see if I agree it's a bug. -- nosy: +jjlee ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3704 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 unhandled exception or crash -- it's a bug, but won't cause the program to stop. And by none of the cookies work after that, you mean that no cookies in headers containing the quoted version cookie-attribute are accepted by the cookiejar. FWIW, this bug only affects RFC 2109 cookies, not RFC 2965 cookies. -- nosy: +jjlee ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3924 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 viewed on the site. Translation to .pdf is indirect via translation to latex and then from latex to .pdf. Since the .html index appears flawless, and since a different .pdf has problems, I suspect that the .pdf index problem is in one of the two translation steps. Hence the change of component. In the meanwhile, either ignore the index or use the html version. Thanks a lot for you reply. I just intend to raise somebody's attention to this problem in order to improve reader's experience. It might or might not be a trivial to fix though. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4027 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue3704 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
