[issue1294959] Problems with /usr/lib64 builds.
Changes by Catalin Iacob iacobcata...@gmail.com: -- nosy: +catalin.iacob ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15631] Python 3.3/3.4 installation issue on OpenSUSE lib/lib64 folders
Catalin Iacob added the comment:
In reply to msg168184, LIBDIR is set to include lib64 instead of lib because
openSUSE explicitly does it that way in their multilib implementation.
More specifically, the CONFIG_SITE environment variable is set to
/usr/share/site/x86_64-unknown-linux-gnu which contains, among more stuff:
catalin@opensuse:~/hacking/cpython cat $CONFIG_SITE | grep libdir
# If user did not specify libdir, guess the correct target:
if test $libdir = '${exec_prefix}/lib' ; then
libdir='${exec_prefix}/lib64'
/usr/share/site/x86_64-unknown-linux-gnu is owned by package site-config whose
README says:
site-config: Site Paths Configuration for autoconf Based configure Scripts
==
Site configuration for autoconf based configure scripts provides smart
defaults for paths that are not specified.
All autoconf based configure scripts will automatically resource site
script using CONFIG_SITE environment variable. It works without any
explicit user interaction.
Currently implemented features:
Automatic libdir setup to $exec_prefix/lib or $exec_prefix/lib64
Depending on architecture, site script should correctly and
automatically switch between lib and lib64 libdir.
libexecdir setup to $exec_prefix/lib
Upstream libexecdir defaults to $exec_prefix/libexec. This directory is
not part of FHS 2.2, so we change it to $exec_prefix/lib (yes, it is
correct to set it to $exec_prefix/lib even for bi-arch platforms). Most
projects add package name to this path, so you most probably get what
FHS 2.2 expects.
--
nosy: +catalin.iacob
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15631
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6972] zipfile.ZipFile overwrites files outside destination path
Catalin Iacob added the comment: There are 2 issues with the documentation changes introduced by these patches. 1. for 2.7, the note added by the doc patch is in the wrong place, at the setpassword method instead of the extract or extractall method 2. for 3.x the Never extract archives from untrusted sources... warning got removed but it's still useful for users that read the documentation online and therefore get the updated docs but haven't updated Python to the latest patch release and therefore don't have the fix. For example, anybody reading the docs for 3.2 or 3.3 today doesn't see that extractall is dangerous and there is no released Python containing the fix so by all practical means extractall is still dangerous today. To address point 2, I think the warning should be kept with an extra mention regarding exact version where it got fixed so that, when reading the documentation, everybody can assess exactly whether extractall is safe for them to use or not. I can't reopen the bug since I don't have tracker privileges but since it's a security issue I think it's important for these to get addressed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6972 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6972] zipfile.ZipFile overwrites files outside destination path
Changes by Catalin Iacob iacobcata...@gmail.com: -- nosy: +catalin.iacob ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6972 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16273] f.tell() returning negative number on Windows build
Catalin Iacob added the comment: Could it be that Raymond's file had Unix line endings? I tried to reproduce this, picked a file on my disk and indeed I got a negative number, but that file has Unix line endings. This is documented at http://docs.python.org/2/library/stdtypes.html#file.tell so probably there's nothing to do then. As for Armin's report in msg180145, even though it's not intuitive, this matches ftell's behavior on Windows, as documented in the Remarks section of http://msdn.microsoft.com/en-us/library/0ys3hc0b%28v=vs.100%29.aspx. The tell() method on fileobjects is explicitly documented as matching ftell behavior: Return the file’s current position, like stdio‘s ftell(). So even though it's not intuitive at all, it's probably better to leave it as is. tell() returns the intuitive non zero position when opening with 'a' on Python3 and on Python 2.7 when using io.open so it's fixed for the future anyway. -- nosy: +catalin.iacob ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16273 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8745] zipimport is a bit slow
Catalin Iacob added the comment: Attached v4 of patch with error checking for getc and some more comments. A real world example of the speedup is Calibre (http://calibre-ebook.com/) which on Windows comes with its own code, its dependecies and Python's stdlib all bundled in a 40MB zip. With the patch the time to create a zipimporter instance from that zip drops from around 60ms to around 15ms. -- Added file: http://bugs.python.org/file28599/zipimport-speedup-v4.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8745 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8745] zipimport is a bit slow
Catalin Iacob added the comment: Yes Serhiy, I was planning to, lack of time followed by (just finished) vacation lead to a stall. Thanks for following up on this. I should soon, probably this weekend, have an updated version addressing your comments. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8745 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5054] CGIHTTPRequestHandler.run_cgi() HTTP_ACCEPT improperly parsed
Changes by Catalin Iacob iacobcata...@gmail.com: -- nosy: +catalin.iacob ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5054 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8745] zipimport is a bit slow
Catalin Iacob added the comment: I tried Serhiy's suggestion in msg174934, see attached attempt-fseek-seek_cur.patch updated to current default. It makes no difference relative to the default branch for my test stdlib.zip, dummy reads still work better on Windows. This makes sense if you follow the CRT's implementation, fseek calls _fseek_nolock which always calls _flush, regardless whether SEEK_CUR is used or not. This is the case with both VS2008 and VS2010. So this patch is a workaround for poor fseek performance in Microsoft's CRT, it doesn't cause performance issues on Linux but saves quite some milliseconds of startup time so I think it's worth the tradeoff. I'll also upload zipimport_speedup-v3.patch updated to apply to current default and with error handling for failing freads since the fseeks that the patch replaces have gained error handling on the default branch in the mean time. The timings remain the same on my Windows machine: around 30ms for default branch, around 15ms with patch. -- Added file: http://bugs.python.org/file28116/attempt-fseek-seek_cur.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8745 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8745] zipimport is a bit slow
Changes by Catalin Iacob iacobcata...@gmail.com: Added file: http://bugs.python.org/file28117/zipimport-speedup-v3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8745 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16472] Distutils+mingw links agains msvcr90, while python27.dll is linked agains msvcrt
Catalin Iacob added the comment: Václav, are you sure about the official python27.dll being linked against msvcrt.dll? Maybe this is your own python27.dll compiled with MinGW? I see the opposite: for both C:\windows\system32\python27.dll (64 bit) and c:\windows\SysWOW64\python27.dll (32 bit) from the Windows 2.7.3 installer, Dependency Walker shows they are linked against msvcr90.dll. This is probably also the reason why distutils links extensions against msvcr90.dll, exactly to avoid linking against 2 different CRTs. -- nosy: +catalin.iacob ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16472 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8745] zipimport is a bit slow
Changes by Catalin Iacob iacobcata...@gmail.com: -- versions: +Python 3.4 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8745 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15991] BaseHTTPServer with ThreadingMixIn serving wrong data sometimes
Catalin Iacob added the comment: Can't reproduce this on openSUSE Factory (development version, what will become 12.3). I tried with openSUSE's Python 2 which is 2.7.3 and with self compiled up to date 2.7 branch from hg. For each of these I bumped the number of files to 3000 instead of 300 and ran the script around 10 times, always got 3000 good 0 bad. -- nosy: +catalin.iacob ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15991 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8713] multiprocessing needs option to eschew fork() under Linux
Changes by Catalin Iacob iacobcata...@gmail.com: -- nosy: +catalin.iacob ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8713 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5053] http.client.HTTPMessage.getallmatchingheaders() always returns []
Catalin Iacob iacobcata...@gmail.com added the comment: So, how to move this further? In #13425 Petri proposes 4 alternatives, copying them here: 1) Document the function to make it officially part of the public API 2) Rename and move the function to http.server 3) Leave it undocumented and just fix it 4) Deprecate the function to be removed in 3.4 or 3.5 and fix it to always return []. I assume 4) meant: 4) Deprecate the function to be removed in 3.4 or 3.5 and fix to do what its docstring specifies. My proposal is a more explicitly spelled out version 2): 5) Remove the function, replace its usage in http.server.CGIHTTPRequestHandler and add a test for http.server.CGIHTTPRequestHandler that exercises the part that currently uses getallmatchingheaders since that's obviously broken now. The rationale for removal without deprecation is: * the function duplicates get_all so there's no reason to have it * it's probably not used by any (working) code because it just doesn't work Mike can you tell us how you found out about this breakage? Were you using the function? Did you use something else to workaround it since it's broken now? Senthil, Petri do you agree with option 5)? If so I can provide a patch. -- nosy: +catalin.iacob ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5053 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12178] csv writer doesn't escape escapechar
Changes by Catalin Iacob iacobcata...@gmail.com: -- nosy: +larry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12178 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8264] hasattr doesn't show private (double underscore) attributes exist
Catalin Iacob iacobcata...@gmail.com added the comment: Attached a patch that adds a note for getattr and setattr. hasattr is documented in terms of getattr so I would say it's not needed there. I don't know if the interaction with private attributes is confusing enough that it's worth increasing the verbosity of the getattr and setattr docs, all in all I think I'm +0 to adding the note and -0 to just closing the bug as by design and no doc change needed. -- keywords: +patch nosy: +catalin.iacob title: hasattr doensn't show private (double underscore) attributes exist - hasattr doesn't show private (double underscore) attributes exist Added file: http://bugs.python.org/file26289/get-set-attr-private-name-mangling.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8264 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12271] panel.h is not found even if it's installed on various flavours of SUSE
Catalin Iacob iacobcata...@gmail.com added the comment:
The same happens on OpenSUSE 12.1 so Python can't be fully built there which is
a bit of a shame.
OpenSUSE uses this patch for their packages, but that would break other
distributions so it's not a good solution:
-#include panel.h
+#include ncurses/panel.h
Here's a list of all curses related files in /usr/include on my OpenSUSE 12.1:
catalin@linux-vo6z:~/cpython/issue12271 find /usr/include/ -regex
'.*curses.*' -and \( -type f -or -type l \) -exec ls -lh {} \;
-rw-r--r-- 1 root root 4.1K May 10 15:28 /usr/include/python2.7/py_curses.h
lrwxrwxrwx 1 root root 16 Nov 20 2011 /usr/include/curses.h - ncurses/curses.h
-rw-r--r-- 1 root root 75K Oct 29 2011 /usr/include/ncurses/curses.h
-rw-r--r-- 1 root root 6.5K Oct 29 2011 /usr/include/ncurses/cursesapp.h
-rw-r--r-- 1 root root 27K Oct 29 2011 /usr/include/ncurses/cursesf.h
-rw-r--r-- 1 root root 20K Oct 29 2011 /usr/include/ncurses/cursesm.h
-rw-r--r-- 1 root root 8.3K Oct 29 2011 /usr/include/ncurses/cursesp.h
-rw-r--r-- 1 root root 49K Oct 29 2011 /usr/include/ncurses/cursesw.h
-rw-r--r-- 1 root root 7.2K Oct 29 2011 /usr/include/ncurses/cursslk.h
-rw-r--r-- 1 root root 2.9K Oct 29 2011 /usr/include/ncurses/eti.h
-rw-r--r-- 1 root root 9.1K Oct 29 2011 /usr/include/ncurses/etip.h
-rw-r--r-- 1 root root 18K Oct 29 2011 /usr/include/ncurses/form.h
-rw-r--r-- 1 root root 12K Oct 29 2011 /usr/include/ncurses/menu.h
-rw-r--r-- 1 root root 4.0K Oct 29 2011 /usr/include/ncurses/nc_tparm.h
lrwxrwxrwx 1 root root 8 Nov 20 2011 /usr/include/ncurses/ncurses.h - curses.h
-rw-r--r-- 1 root root 3.9K Oct 29 2011 /usr/include/ncurses/ncurses_dll.h
-rw-r--r-- 1 root root 4.0K Oct 29 2011 /usr/include/ncurses/panel.h
-rw-r--r-- 1 root root 40K Oct 29 2011 /usr/include/ncurses/term.h
-rw-r--r-- 1 root root 7.2K Oct 29 2011 /usr/include/ncurses/term_entry.h
-rw-r--r-- 1 root root 3.5K Oct 29 2011 /usr/include/ncurses/termcap.h
-rw-r--r-- 1 root root 13K Oct 29 2011 /usr/include/ncurses/tic.h
-rw-r--r-- 1 root root 3.1K Oct 29 2011 /usr/include/ncurses/unctrl.h
lrwxrwxrwx 1 root root 17 Nov 20 2011 /usr/include/ncurses.h -
ncurses/ncurses.h
lrwxrwxrwx 1 root root 16 Nov 20 2011 /usr/include/ncurses6/curses.h -
ncurses/curses.h
-rw-r--r-- 1 root root 75K Oct 29 2011 /usr/include/ncurses6/ncurses/curses.h
-rw-r--r-- 1 root root 6.5K Oct 29 2011
/usr/include/ncurses6/ncurses/cursesapp.h
-rw-r--r-- 1 root root 27K Oct 29 2011 /usr/include/ncurses6/ncurses/cursesf.h
-rw-r--r-- 1 root root 20K Oct 29 2011 /usr/include/ncurses6/ncurses/cursesm.h
-rw-r--r-- 1 root root 8.3K Oct 29 2011 /usr/include/ncurses6/ncurses/cursesp.h
-rw-r--r-- 1 root root 49K Oct 29 2011 /usr/include/ncurses6/ncurses/cursesw.h
-rw-r--r-- 1 root root 7.2K Oct 29 2011 /usr/include/ncurses6/ncurses/cursslk.h
-rw-r--r-- 1 root root 2.9K Oct 29 2011 /usr/include/ncurses6/ncurses/eti.h
-rw-r--r-- 1 root root 9.1K Oct 29 2011 /usr/include/ncurses6/ncurses/etip.h
-rw-r--r-- 1 root root 18K Oct 29 2011 /usr/include/ncurses6/ncurses/form.h
-rw-r--r-- 1 root root 12K Oct 29 2011 /usr/include/ncurses6/ncurses/menu.h
-rw-r--r-- 1 root root 4.0K Oct 29 2011
/usr/include/ncurses6/ncurses/nc_tparm.h
lrwxrwxrwx 1 root root 8 Nov 20 2011 /usr/include/ncurses6/ncurses/ncurses.h
- curses.h
-rw-r--r-- 1 root root 3.9K Oct 29 2011
/usr/include/ncurses6/ncurses/ncurses_dll.h
-rw-r--r-- 1 root root 4.0K Oct 29 2011 /usr/include/ncurses6/ncurses/panel.h
-rw-r--r-- 1 root root 40K Oct 29 2011 /usr/include/ncurses6/ncurses/term.h
-rw-r--r-- 1 root root 7.2K Oct 29 2011
/usr/include/ncurses6/ncurses/term_entry.h
-rw-r--r-- 1 root root 3.5K Oct 29 2011 /usr/include/ncurses6/ncurses/termcap.h
-rw-r--r-- 1 root root 13K Oct 29 2011 /usr/include/ncurses6/ncurses/tic.h
-rw-r--r-- 1 root root 3.1K Oct 29 2011 /usr/include/ncurses6/ncurses/unctrl.h
lrwxrwxrwx 1 root root 17 Nov 20 2011 /usr/include/ncurses6/ncurses.h -
ncurses/ncurses.h
-rw-r--r-- 1 root root 92K Oct 29 2011 /usr/include/ncurses6/ncursesw/curses.h
If we look just for panel.h we get:
catalin@linux-vo6z:~/cpython/issue12271 find /usr/include/ -regex
'.*curses.*' -and \( -type f -or -type l \) -exec ls -lh {} \; | grep panel.h
-rw-r--r-- 1 root root 4.0K Oct 29 2011 /usr/include/ncurses/panel.h
-rw-r--r-- 1 root root 4.0K Oct 29 2011 /usr/include/ncurses6/ncurses/panel.h
-rw-r--r-- 1 root root 4.0K Oct 29 2011 /usr/include/ncurses6/ncursesw/panel.h
-rw-r--r-- 1 root root 4.0K Oct 29 2011 /usr/include/ncursesw/panel.h
There is some specific code that appends '/usr/include/ncursesw' to the include
list in setup.py but that doesn't get triggered here because curses_library ==
'ncurses' because readline is built against that.
The attached patch makes it build and the curses tests pass but it feels kind
of hack-ish. panel.h is there so Python should find it somehow therefore this
is a genuine bug. Ideas for a better solution?
--
keywords
[issue15014] smtplib: add support for arbitrary auth methods
Changes by Catalin Iacob iacobcata...@gmail.com: -- nosy: +catalin.iacob ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15014 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8745] zipimport is a bit slow
Catalin Iacob iacobcata...@gmail.com added the comment: I updated Goplat's patch to the default branch. It now needs to read 4 dummy bytes instead of 6 since an extra PyMarshal_ReadShortFromFile was added to the default branch in the mean time. I added an explicit dummy buffer instead of reading the dummy bytes into name (for cleanness and because name would overflow on hypothetical platforms where MAXPATHLEN + 5 8). Also added tests for the loop that skips the rest of the header by creating some zips with file comments; without the extra test, commenting out the loop didn't fail test_zipimport. Running Goplat's test in msg106191 on Windows I get 0.032 sec before and 0.015 sec after. On Linux I see no significant difference. AFAIK Mercurial (for example) ships with a zipped stdlib on Windows and they care quite a lot about startup time. Can this make it into 3.3? -- nosy: +catalin.iacob versions: +Python 3.3 -Python 3.2 Added file: http://bugs.python.org/file25823/zipimport_speedup-v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8745 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13641] decoding functions in the base64 module could accept unicode strings
Catalin Iacob iacobcata...@gmail.com added the comment: Attached v2 of patch where mixing str and binary data for altchars or map01 raises TypeError. I also added a note for each of the changed functions that it also accepts strings (but didn't also update the docstrings). When writing the docs, the new functionality seemed hard to describe; maybe that means this issue only complicates things and is not worth it, or maybe it just means I don't have experience at writing docs. But, regardless of having worked at a patch, I have to admit that I'm also not 100% sure this issue is a good idea. I *do* think that either both this issue and #13637 should be accepted or both rejected. -- Added file: http://bugs.python.org/file24565/issue13641-alternative-v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13641 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13641] decoding functions in the base64 module could accept unicode strings
Catalin Iacob iacobcata...@gmail.com added the comment: My current patch allows mixing of bytes and str for the data to be decoded and the altchars or map01 parameter. Given David's observation in msg153505 I'll update the patch to require that both the data and altchars/map01 have the same type. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13641 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13641] decoding functions in the base64 module could accept unicode strings
Catalin Iacob iacobcata...@gmail.com added the comment: Attached alternative patch with a different approach: on input, strings are encoded as bytes and the rest of the code proceeds as before. All existing tests for bytes now test for strings as well and there is a new test for strings with non ASCII characters. Berker's patch was more intrusive and forgot to allow strings in _translate, leading to failures if altchars or map01 were used. -- nosy: +catalin.iacob Added file: http://bugs.python.org/file24533/issue13641-alternative-v1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13641 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8739] Update to smtpd.py to RFC 5321
Changes by Catalin Iacob iacobcata...@gmail.com: -- nosy: +catalin.iacob ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8739 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13905] Built-in Types Comparisons should mention rich comparison methods
New submission from Catalin Iacob iacobcata...@gmail.com: In 2.7 the Comparisons section of stdtypes.rst only talks about __cmp__ and never mentions the rich comparison methods: Instances of a class normally compare as non-equal unless the class defines the __cmp__() method. Refer to Basic customization) for information on the use of this method to effect object comparisons. The first sentence is false, instances can also compare as equal if they define __eq__. And since __cmp__ is gone in Python3, I think the rich comparison methods should at least be mentioned, or even emphasized over __cmp__ to help people write more forward compatible code. -- assignee: docs@python components: Documentation messages: 152254 nosy: catalin.iacob, docs@python priority: normal severity: normal status: open title: Built-in Types Comparisons should mention rich comparison methods type: enhancement versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13905 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13905] Built-in Types Comparisons should mention rich comparison methods
Catalin Iacob iacobcata...@gmail.com added the comment: Here's my attempt at a patch. It mostly takes the text from the default branch and adds references to __cmp__. -- keywords: +patch Added file: http://bugs.python.org/file24361/issue13905v1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13905 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10042] total_ordering
Changes by Catalin Iacob iacobcata...@gmail.com: -- nosy: +catalin.iacob ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10042 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
Changes by Catalin Iacob iacobcata...@gmail.com: -- nosy: +catalin.iacob ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9116] test_capi.test_no_FatalError_infinite_loop crash on Windows
Changes by Catalin Iacob iacobcata...@gmail.com: -- nosy: +catalin.iacob ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9116 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5619] Pass MS CRT debug flags into subprocesses
Changes by Catalin Iacob iacobcata...@gmail.com: -- nosy: +catalin.iacob ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5619 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11732] Skip decorator for tests requiring manual intervention on Windows
Changes by Catalin Iacob iacobcata...@gmail.com: -- nosy: +catalin.iacob ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11732 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11732] Skip decorator for tests requiring manual intervention on Windows
Catalin Iacob iacobcata...@gmail.com added the comment: To avoid messing with system registry settings it sounds like WerRegisterRuntimeExceptionModule could also work, at least on Windows7 http://msdn.microsoft.com/en-us/library/windows/desktop1/dd408167%28v=VS.85%29.aspx There could be a dll which would do nothing when receiving the crash report for expected crashes (test_capi and test_faulthandler). WerRegisterRuntimeExceptionModule doesn't exist in the headers of the SDK that comes with VS2008 but it could be retrieved at runtime with GetProcAddress. It's more work than the registry setting but seems cleaner since it avoids changing system settings. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11732 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12611] 2to3 crashes when converting doctest using reduce()
Catalin Iacob iacobcata...@gmail.com added the comment: I looked at this and understood why it's happening. I don't know exactly how to fix it though, so here's what I found out. When a doctest appears in a docstring at line n in a file, RefactorTool.parse_block will return a tree corresponding to n - 1 newline characters followed by the code in the doctest. That tree is refactored by RefactoringTool.refactor_tree which usually returns n - 1 newline characters followed by the refactored doctest. However, for the reduce fixer, the tree returned by refactor_tree starts with from functools import reduce followed by n - 1 newline characters and then the doctest reduce line. The failing assert happens when stripping those newlines because they are expected to be at the beginning of the output while in reality they're after the import line. So the problem is a mismatch between the expectations of the doctest machinery (refactoring code that starts with some newlines results in code that starts with the same number of newlines) and the reduce fixer which adds an import, imports are added at the beginning of the file, therefore something appears before the newlines. Other fixers could exhibit the same problem. -- nosy: +catalin.iacob ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12577] Misleading shutil.move docs regarding when os.rename is used
Catalin Iacob iacobcata...@gmail.com added the comment: Senthil's proposal in msg140543 has +1 from me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12577 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12577] Misleading shutil.move docs regarding when os.rename is used
New submission from Catalin Iacob iacobcata...@gmail.com: I recently tried to answer the question: When moving a file to a destination that is an already existing file, is the destination overwritten? From the current docs I understood that if src and dst are on the same filesystem then os.rename is used, if they are on different filesystems then copy + remove is used instead. Since os.rename fails on Windows if the destination exists I concluded that shutil.move would fail on Windows and overwrite dst on Unix. -- assignee: docs@python components: Documentation messages: 140520 nosy: catalin.iacob, docs@python priority: normal severity: normal status: open title: Misleading shutil.move docs regarding when os.rename is used versions: Python 2.7, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12577 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12577] Misleading shutil.move docs regarding when os.rename is used
Catalin Iacob iacobcata...@gmail.com added the comment: Attached patch which clarifies that the copy fallback is used whenever os.rename fails not just for the different filesystems case. -- keywords: +patch Added file: http://bugs.python.org/file22679/clarify-shutil.move-docs.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12577 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7484] smtplib: verify breaks with Postfix servers
Catalin Iacob iacobcata...@gmail.com added the comment: I looked at the Felipe's patch and hopefully made some improvements. Unlike Felipe's patch I didn't change the reply of the SMTP server in the tests but instead use what VRFY and EXPN actually send to index the users and lists dictionaries. If would be sent the lookup would fail. Similarly, when VRFY return 550 it echoed the address as received and now it's tested to be equal to something without . By the way, but I was wondering: * is the try/except really needed or just a historical artifact (why would email.utils.parseaddr raise AttributeError?) * is the test to None correct? It was added by the fix to issue1430298 but does email.utils.parseaddr ever return None for the address? (I could only get it to return '') I kept quoteaddr as is to make it easier to review the patch but if David confirms the above points are valid I can create new issues for them and simplify/fix quoteaddr. -- hgrepos: +43 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7484 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7484] smtplib: verify breaks with Postfix servers
Changes by Catalin Iacob iacobcata...@gmail.com: Added file: http://bugs.python.org/file22680/88b5c7ab7a03.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7484 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12178] csv writer doesn't escape escapechar
Catalin Iacob iacobcata...@gmail.com added the comment: I looked at this and tried to provide a patch + tests. Please review. The bug is that a writer can use writerow on some input data but if a reader with the same dialect reads them back they are different from the input ones. This happens when the input data contains escapechar. Contrary to msg136881, this happens regardless whether doublequote is True or False. The docs say On reading, the escapechar removes any special meaning from the following character. Therefore, I understand that on writing, escapechar must always be escaped by itself. If that doesn't happen, when reading it back, escapechar alters the thing that follows it instead of counting as escapechar which is precisely what this bug is about. -- hgrepos: +38 nosy: +catalin.iacob ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12178 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12178] csv writer doesn't escape escapechar
Changes by Catalin Iacob iacobcata...@gmail.com: -- keywords: +patch Added file: http://bugs.python.org/file22596/0eb420ce6567.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12178 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12378] smtplib.SMTP_SSL leaks socket connections on SSL error
Changes by Catalin Iacob iacobcata...@gmail.com: -- nosy: +catalin.iacob ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12378 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12378] smtplib.SMTP_SSL leaks socket connections on SSL error
Catalin Iacob iacobcata...@gmail.com added the comment: Just a note after running Joe's example. smtplib is affected by this issue in 3.x, but the example produces different results in 3.x: smtpd doesn't keep the connection open due to UnicodeDecodeError when the data from the ssl handshake cannot be decoded as utf-8: error: uncaptured python exception, closing channel __main__.SMTPChannel connected 127.0.0.1:34160 at 0xb739a4cc (class 'UnicodeDecodeError':'utf8' codec can't decode bytes in position 13-14: invalid continuation byte [/mnt/data/catalin/hacking/cpython/default/Lib/asyncore.py|read|83] [/mnt/data/catalin/hacking/cpython/default/Lib/asyncore.py|handle_read_event|442] [/mnt/data/catalin/hacking/cpython/default/Lib/asynchat.py|handle_read|190] [/mnt/data/catalin/hacking/cpython/default/Lib/smtpd.py|collect_incoming_data|278]) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12378 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4470] smtplib SMTP_SSL not working.
Catalin Iacob iacobcata...@gmail.com added the comment: Most of the problems in this issue were solved already so it could almost be closed: * patch 1 was addressed in #11927 * patch 2 was addressed in #4066 * patches 3 and 4 were addressed in #11893 Torsten's problem was addressed by bcf04ced5ef1. I'm not sure what is left to do in this issue. The only patch remaining is patch 5. I attached an updated version against tip of default branch. My patch mimics shutdown in imaplib.py in that it silences ENOTCONN. However I don't have a test that fails without the shutdown and I don't know if checking ENOTCONN is really needed. I tried to get shutdown to produce ENOTCONN by using Postfix as a server with smtpd_timeout=5s, connecting to it and waiting idle for more than 5 seconds before doing close(). In the Postfix logs I see that Postfix disconnects after 5 seconds of inactivity but doing shutdown afterwards doesn't trigger any exception so the ENOTCONN part remains unexercised. My patch also adds shutdown method and SHUT_RDWR constant to mock_socket.py since otherwise test_smtplib fails. (Added Antoine to nosy because he reviewed the patches for #11927 and #11893) -- nosy: +catalin.iacob, pitrou Added file: http://bugs.python.org/file22398/smtplib_05_shutdown_socket_v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4470 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11893] Obsolete SSLFakeFile in smtplib?
Catalin Iacob iacobcata...@gmail.com added the comment:
Attached v1 of patch. Please review.
There are some tests using GMail in test_smtpnet.py. They still pass with the
patch. I also did manual tests with GMail with both SMTP + starttls and
SMTP_SSL.
The idea of the patch is that SMTP.getreply is already doing:
if self.file is None:
self.file = self.sock.makefile('rb')
Therefore, the patch invalidates self.file by setting it to None every time
self.sock is (re-)assigned to something.
For consistency, setting self.file to None is also done in LMTP.connect when
setting self.sock to a Unix socket although it's not necessarily needed there.
Not doing this makes the following scenario fail: create an LMTP instance, call
connect, send and read some data (self.file gets initialized), call connect
again with an Unix socket, reading more data now uses self.file referring to
old socket. But I'm not sure if this scenario is a bug or a misuse of the API,
aka you shouldn't call connect twice on the same instance.
Note that I didn't test LMTP. Should I or is it obvious enough that the change
is ok?
--
keywords: +patch
nosy: +catalin.iacob
Added file: http://bugs.python.org/file22171/remove_sslfakefile_v1.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11893
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12161] StringIO AttributeError instead of ValueError after close..
Catalin Iacob iacobcata...@gmail.com added the comment: Attached patch + test case. Also tested cStringIO in 2.7 and io.StringIO in 3.2 and 3.3 tip and they aren't affected. -- keywords: +patch nosy: +catalin.iacob Added file: http://bugs.python.org/file22116/12161.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12161 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12034] check_GetFinalPathNameByHandle() suboptimal
Catalin Iacob iacobcata...@gmail.com added the comment: I looked at providing a patch for this issue as an introductory step (this would be my first patch). But when following the code I discovered that the case that this issue is trying to optimize is never executed in current CPython. In that case, there isn't much value in optimizing it. More precisely, check_GetFinalPathNameByHandle is called by posix__getfinalpathname which is nt._getfinalpathname in Python code. If the check fails, posix__getfinalpathname throws NotImplmenentedError. But nt._getfinalpathname is only used by ntpath.py which checks the Windows version and only calls nt._getfinalpathname for Vista and higher where the check won't fail. To me it would make more sense that the nt module has a _getfinalpathname attribute only if it supports the feature instead of always having one that throws NotImplementedError. In that case, ntpath.py would not check the Windows version but the presence of _getfinalpathname in the nt module. Does this seem like a better approach to you, at least theoretically? And if so, is it worth implementing it? Thanks for any advice. -- nosy: +catalin.iacob ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12034 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12031] subprocess module does not accept file twice
Catalin Iacob iacobcata...@gmail.com added the comment: I can reproduce this on 3.2 final but not on the tip of the 3.2 branch so it seems to have been fixed. -- nosy: +catalin.iacob ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12031 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7484] smtplib: verify breaks with Postfix servers
Changes by Catalin Iacob iacobcata...@gmail.com: -- nosy: +catalin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7484 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3244] multipart/form-data encoding
Changes by Catalin Iacob iacobcata...@gmail.com: -- nosy: +catalin.iacob ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3244 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue459007] Document sys.path on Windows
Changes by Catalin Iacob iacobcata...@gmail.com: -- nosy: +catalin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue459007 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
