[issue25846] Use of Py_ARRAY_LENGTH on pointer in posixmodule.c, win32_wchdir

Alexander Riccio added the comment: > Are you aware of the Coverity program? Last time I heard about Coverity, > CPython had 0 bug found by Coverity ;-) Yup, see Issue25847. > The sad part is that Py_ARRAY_LENGTH() is written for static analysis Sadly, yeah. MSVC, when compiling as C++, shoul

[issue12923] test_urllib fails in refleak mode

Martin Panter added the comment: I guess this is a real bug so should also be applied to Python 2. This patch combines the previous three, and tweaks a couple things: * Rename the test function * Drop irrelevant header lines -- components: +Library (Lib) versions: +Python 2.7, Python 3

[issue25847] CPython not using Visual Studio code analysis!

Alexander Riccio added the comment: > Is analyze something that can be used from the command line only, or does it > require the GUI? You can do it from the command line - Chrome/chromium makes use of it as such. See: https://code.google.com/p/chromium/issues/detail?id=427616 The /analyze opt

[issue11072] Add MLSD command support to ftplib

Roundup Robot added the comment: New changeset ecef6b3f6639 by Gregory P. Smith in branch '3.5': Issue #11072: change the incorrect "deprecation" of ftplib dir() and nlst() https://hg.python.org/cpython/rev/ecef6b3f6639 New changeset 287bb82768a7 by Gregory P. Smith in branch 'default': Issue #1

[issue22088] base64 module still ignores non-alphabet characters

Martin Panter added the comment: While porting the Python 3 changes over, I noticed some related problems in the Python 2 and 3 documentation: * Due to the internal alphabet translation, characters that are in the original base-64 alphabet (+ and /) are not discarded, even if an alternative al

[issue20782] base64 module docs do not use the terms 'bytes' and 'string' consistently.

Martin Panter added the comment: Hopefully the patch proposed for Issue 1753718 will address this issue. Many of my comments there would also apply to the patch here. -- dependencies: +base64 "legacy" functions violate RFC 3548 nosy: +martin.panter stage: needs patch -> patch review __

[issue22088] base64 module still ignores non-alphabet characters

Roundup Robot added the comment: New changeset 937774aa1853 by Martin Panter in branch '2.7': Issue #22088: Port base64 character ignoring doc and test from 857d9fe60169 https://hg.python.org/cpython/rev/937774aa1853 -- nosy: +python-dev ___ Python tr

[issue19284] subprocess._args_from_interpreter_flags() mishandles -R

Roundup Robot added the comment: New changeset d76b9c121e61 by Gregory P. Smith in branch '3.4': Re-fix issue #19284: Don't generate the no-op -R command line https://hg.python.org/cpython/rev/d76b9c121e61 New changeset 014e6f7d7c1a by Gregory P. Smith in branch '3.5': * Re-fix issue #19284: Don

[issue25822] Add docstrings to fields of urllib.parse results

Raymond Hettinger added the comment: I wouldn't normally write a test for a docstring patch. -- ___ Python tracker ___ ___ Python-bugs

[issue25822] Add docstrings to fields of urllib.parse results

Changes by Swati Jaiswal : Added file: http://bugs.python.org/file41300/iss_25822_3.patch ___ Python tracker ___ ___ Python-bugs-list mailing

[issue25857] csv: unexpected result

Ioan Fintescu added the comment: You may be right. I just saved it from LibreOffice Calc and I got [x=”a”,"y=”b, c”"]. I thought the original was saved from a spreadsheet program. ...muss On Sun, Dec 13, 2015 at 7:51 PM, Ioan Fintescu wrote: > You wrote ['x = "a"', 'y = "b, c"'] > I wrote [

[issue25858] Structure field size/ofs __str__ wrong with large size fields

Changes by Charles Machalow : Removed file: http://bugs.python.org/file41298/ctypesBug.py ___ Python tracker ___ ___ Python-bugs-list mailing

[issue20837] Ambiguity words in base64 documentation

Martin Panter added the comment: I think it is too late for 3.3 now, but I did port the relevant bit to 2.7. -- nosy: +martin.panter stage: patch review -> resolved status: open -> closed versions: +Python 2.7 -Python 3.3 ___ Python tracker

[issue25858] Structure field size/ofs __str__ wrong with large size fields

Changes by Charles Machalow : Added file: http://bugs.python.org/file41299/ctypesBug.py ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue25858] Structure field size/ofs __str__ wrong with large size fields

Charles Machalow added the comment: Adding file with code to reproduce. -- Added file: http://bugs.python.org/file41298/ctypesBug.py ___ Python tracker ___ __

[issue20837] Ambiguity words in base64 documentation

Roundup Robot added the comment: New changeset e8cbebb273c6 by Martin Panter in branch '2.7': Issue #20837: Base-64 alphabet clarification from revision 1853679c6f71 https://hg.python.org/cpython/rev/e8cbebb273c6 -- ___ Python tracker

[issue25858] Structure field size/ofs __str__ wrong with large size fields

Changes by Charles Machalow : Removed file: http://bugs.python.org/file41297/ctypesBug.py ___ Python tracker ___ ___ Python-bugs-list mailing

[issue25858] Structure field size/ofs __str__ wrong with large size fields

New submission from Charles Machalow: Large sized fields in Structures lead to incorrect string representations because it is assuming that because the size is so large, it must be a bit field instead of a byte field. class bugStruct(Structure): _pack_ = 1 _fields_ = [

[issue25857] csv: unexpected result

Ioan Fintescu added the comment: You wrote ['x = "a"', 'y = "b, c"'] I wrote ['x = "a", y = "b, c"'] ...muss On Sun, Dec 13, 2015 at 7:08 PM, R. David Murray wrote: > > R. David Murray added the comment: > > >>> b = io.StringIO() > >>> w = csv.writer(b) > >>> w.writerow(['x = "a"', 'y = "b, c

[issue1753718] base64 "legacy" functions violate RFC 3548

Martin Panter added the comment: Left some review comments. I left a comment about the original patch as well, because I didn’t notice the new patch in time :) Also, maybe we should say the input to the “legacy” MIME decode() function should be multiple lines, since it calls readline() with no

[issue23894] lib2to3 doesn't recognize rb'...' as a raw byte string in Python 3

Changes by Joseph Gordon : -- nosy: +josephgordon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.

[issue24249] unittest API for detecting test failure in cleanup/teardown

Changes by Joseph Gordon : -- nosy: +josephgordon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.

[issue14019] Unify tests for str.format and string.Formatter

Changes by Joseph Gordon : -- nosy: +josephgordon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.

[issue11551] test_dummy_thread.py test coverage improvement

Changes by Joseph Gordon : -- nosy: +josephgordon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.

[issue25857] csv: unexpected result

R. David Murray added the comment: >>> b = io.StringIO() >>> w = csv.writer(b) >>> w.writerow(['x = "a"', 'y = "b, c"']) 28 >>> b.getvalue() '"x = ""a""","y = ""b, c"""\r\n' In other words, your input was not validly quoted csv. -- nosy: +r.david.murray resolution: -> not a bug stage

[issue25857] csv: unexpected result

New submission from Ioan Fintescu: Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:44:40) [MSC v.1600 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import csv >>> s = 'x = "a", y = "b, c"' >>> s 'x = "a", y = "b, c"' >>> for row in csv.rea

[issue25495] binascii documentation incorrect

Martin Panter added the comment: Thanks for fixing this up David -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue1753718] base64 "legacy" functions violate RFC 3548

R. David Murray added the comment: I started tweaking this patch, and wound up going through the whole doc and fixing the references to 'byte string' and 'string' throughout, as well as making all the entries consistent in how they reference the function arguments and output (previously some d

[issue25750] tp_descr_get(self, obj, type) is called without owning a reference to "self"

François Bissey added the comment: Will Jeroen's patch make it into 2.7.12 or are you expecting more stuff before committing a change? -- nosy: +fbissey ___ Python tracker ___ _

[issue25846] Use of Py_ARRAY_LENGTH on pointer in posixmodule.c, win32_wchdir

STINNER Victor added the comment: > The other occurrence is not fixed. Oops, right. Good catch. This is what happens when I skip the code review step :-/ Is it better with the second change? -- versions: +Python 3.4, Python 3.5 ___ Python tracker <

[issue25846] Use of Py_ARRAY_LENGTH on pointer in posixmodule.c, win32_wchdir

Roundup Robot added the comment: New changeset aba6caf7b9f0 by Victor Stinner in branch '3.5': Issue #25846: Fix usage of Py_ARRAY_LENGTH() in win32_wchdir() (new try) https://hg.python.org/cpython/rev/aba6caf7b9f0 -- ___ Python tracker

[issue25495] binascii documentation incorrect

R. David Murray added the comment: I kept the 57 as part of an historical note explaining why the newline is added. I dropped that sentence in the 3.6 docs, where a keyword to control the apending of the newline has been added. -- resolution: -> fixed stage: patch review -> resolved

[issue25495] binascii documentation incorrect

Roundup Robot added the comment: New changeset 7b137466e879 by R David Murray in branch '2.7': #25495: Clarify b2a_base64 documentation vis 57 bytes. https://hg.python.org/cpython/rev/7b137466e879 New changeset 3d5bf9bd15a3 by R David Murray in branch '3.4': #25495: Clarify b2a_base64 documentat

[issue19284] subprocess._args_from_interpreter_flags() mishandles -R

Gregory P. Smith added the comment: ironically this change would've been a lot simpler had it simply deleted hash_randomization from the set of sys.flags considered by _args_from_interpreter_flags(). -R is always enabled in Python 3.4. it cannot be disabled. it isn't even documented as a co

[issue20954] Bug in subprocess._args_from_interpreter_flags causes MemoryError

Changes by Gregory P. Smith : -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue20954] Bug in subprocess._args_from_interpreter_flags causes MemoryError

Gregory P. Smith added the comment: _args_from_interpreter_flags really deserves its own unittest using a stubbed out sys.flags. if someone wants to go ahead with the test provided in the existing patch here or write one of those, feel free. As is, i've committed a patch logically equivalent

[issue20954] Bug in subprocess._args_from_interpreter_flags causes MemoryError

Roundup Robot added the comment: New changeset d42f6ce08362 by Gregory P. Smith in branch '2.7': Fixes issue #20954: _args_from_interpreter_flags used by multiprocessing https://hg.python.org/cpython/rev/d42f6ce08362 -- nosy: +python-dev ___ Python tr

[issue25846] Use of Py_ARRAY_LENGTH on pointer in posixmodule.c, win32_wchdir

Serhiy Storchaka added the comment: The other occurrence is not fixed. -- nosy: +serhiy.storchaka status: closed -> open ___ Python tracker ___ __

[issue25846] Use of Py_ARRAY_LENGTH on pointer in posixmodule.c, win32_wchdir

STINNER Victor added the comment: > > I found this while writing up a separate bug (CPython doesn't use static > > analysis!). The sad part is that Py_ARRAY_LENGTH() is written for static analysis, but it only works with some compilaters, and for example it doesn't work with Visual Studio, th

[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions

Changes by STINNER Victor : -- nosy: -haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python

[issue20954] Bug in subprocess._args_from_interpreter_flags causes MemoryError

STINNER Victor added the comment: The fix for Lib/subprocess.py looks good to me, but the test doesn't fail without the fix, so the test doesn't look good to me: $ ./python -m test.regrtest -v test_multiprocessing_subprocess At least, the test doesn't ensure that the bug is fixed. --

[issue25846] Use of Py_ARRAY_LENGTH on pointer in posixmodule.c, win32_wchdir

STINNER Victor added the comment: > I found this while writing up a separate bug (CPython doesn't use static > analysis!). Are you aware of the Coverity program? Last time I heard about Coverity, CPython had 0 bug found by Coverity ;-) -- ___ Pytho

[issue25846] Use of Py_ARRAY_LENGTH on pointer in posixmodule.c, win32_wchdir

Roundup Robot added the comment: New changeset 39ce98d9b6b7 by Victor Stinner in branch '3.5': Issue #25846: Fix usage of Py_ARRAY_LENGTH() in win32_wchdir() https://hg.python.org/cpython/rev/39ce98d9b6b7 New changeset e373ec3c2969 by Victor Stinner in branch 'default': (Merge 3.5) Issue #25846:

[issue25846] Use of Py_ARRAY_LENGTH on pointer in posixmodule.c, win32_wchdir

STINNER Victor added the comment: Oh, it's a regression introduced by: changeset: 87516:46aecfc5e374 user:Victor Stinner date:Sun Nov 24 19:23:25 2013 +0100 files: Modules/posixmodule.c description: Issue #19636: Fix usage of MAX_PATH in posixmodule.c -- __

[issue25823] Speed-up oparg decoding on little-endian machines

STINNER Victor added the comment: > I verified that Clang and GCC both give the expected disassembly with > Serhiy's patch. We ought to restrict the #if to just the compilers that are > known to optimize away the memcpy. Yes, it makes sense. Note: Python already has Py_MEMCPY() to work arou

[issue25234] test_eintr.test_os_open hangs under Xcode 7

STINNER Victor added the comment: > I'm still getting the occasional hang for this so I'm going to skip the test > under OS X. Go ahead. I'm not interested to analyze bugs of closed source kernels. -- ___ Python tracker

[issue25696] "make -j9 install" fails because bininstall target requires the libainstall target

STINNER Victor added the comment: > Please go ahead with bininstall-3.patch if you prefer. Ok done. > It certainly avoids the problem you reported. Although I still encourage you > to not add the dash before the command. Oops, fixed. -- resolution: -> fixed status: open -> closed _

[issue25696] "make -j9 install" fails because bininstall target requires the libainstall target

Roundup Robot added the comment: New changeset 94910d210ef4 by Victor Stinner in branch '2.7': Issue #25696: Don't ignore errors in 'make bininstall' on creating $(LIBPC) directory https://hg.python.org/cpython/rev/94910d210ef4 New changeset d28268c47421 by Victor Stinner in branch '3.5': Issue

[issue25696] "make -j9 install" fails because bininstall target requires the libainstall target

Roundup Robot added the comment: New changeset c03ef448b5b2 by Victor Stinner in branch '2.7': Issue #25696: Fix installation of Python on UNIX with make -j9. https://hg.python.org/cpython/rev/c03ef448b5b2 New changeset 87d96b349ff5 by Victor Stinner in branch '3.5': Issue #25696: Fix installati

[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions

Nir Cohen added the comment: I would love some comments (and PRs, of course) on ld. Wanna make it as robust as possible. -- ___ Python tracker ___ ___

[issue25843] lambdas on the same line may incorrectly share code objects

Armin Rigo added the comment: That's what I suggested ("compile.c:compiler_addop(): special-case code objects too, and stick their identity in the tuple 't'.") and how I fixed the same bug in PyPy (https://bitbucket.org/pypy/pypy/commits/7ec3e1d02197). -- _

[issue22137] Test imaplib API on all methods specified in RFC 3501

R. David Murray added the comment: I'm afraid I don't remember the details of our conversations at PyCon. Specifically, I don't remember what problem(s) it is you are trying to solve with this patch. What is the reason for not just adding your new tests to the ThreadedNetworkTests test case?

[issue25843] lambdas on the same line may incorrectly share code objects

Emanuel Barry added the comment: I'm not suggesting to get rid of the rich compare ability of code objects, which makes sense to me. What doesn't make sense to me, however, is when a function's code object is replaced by another one because it compares equal. I see no use case for this, and on

[issue25849] files, opened in unicode (text): write() returns symbols count, but seek() expect offset in bytes

R. David Murray added the comment: I'm still not seeing a bug. If you have a performance enhancement or functional enhancement you'd like us to consider, please attach a patch, with benchmark results. Since you say "are quite slow because of the reconstruction algorithm", what makes you say t

[issue24203] Deprecate threading.Thread.isDaemon etc

R. David Murray added the comment: Well, the idea would be to do a documentation-only deprecation; as in, effectively: this is the older API, you probably really want to use this newer API that is more convenient. I don't have a strong opinion either way in this case. -- nosy: +r.dav

[issue25843] lambdas on the same line may incorrectly share code objects

Serhiy Storchaka added the comment: I suppose this is needed above all for testing. test_compile, test_codeop, test_marshal, and few other tests compare code objects. -- ___ Python tracker

[issue13033] Add shutil.chowntree

Марк Коренберг added the comment: note, that there are many other usecases for that function, like chattr, chmod g+w, touch and so on. But I'm personally consider this will bloat python library, since everyone can write it's own cycle over os.walk() in his program. Also, chown itself is allow

[issue13033] Add shutil.chowntree

Марк Коренберг added the comment: Instead, it may be desirable to implement wrapper over ow.walk() that apply given function to every member. i.e.: recursive_apply('/some/dir', lambda x: os.chown(x, 42, 42)) -- nosy: +mmarkk ___ Python tracker

[issue25849] files, opened in unicode (text): write() returns symbols count, but seek() expect offset in bytes

Марк Коренберг added the comment: https://docs.python.org/3.5/library/io.html?highlight=stringio#id3 : Also, TextIOWrapper.tell() and TextIOWrapper.seek() are both quite slow due to the reconstruction algorithm used. What is reconstruction algorightm ? Experiments show, that seek() and tell()

[issue25843] lambdas on the same line may incorrectly share code objects

Emanuel Barry added the comment: Nobody seems to have asked this, so I'll be that guy. In which circumstances does comparing two code objects (at function creation time, what's more) make any sense? I mean, I'm fine with being able to compare two code objects, but I don't think that's somethin

[issue25856] The __module__ attribute of itertools members is not interned

New submission from Serhiy Storchaka: One of purposes of the STACK_GLOBAL opcode introduced in pickle protocol 4 is to avoid repeating module name for different globals of the same module. >>> pickletools.dis(pickletools.optimize(pickle.dumps([sys.getsizeof, >>> sys.intern], 4))) 0: \x80 P

[issue13033] Add shutil.chowntree

Changes by Berker Peksag : -- nosy: +berker.peksag stage: -> patch review versions: +Python 3.6 -Python 3.3 ___ Python tracker ___ __

[issue25843] lambdas on the same line may incorrectly share code objects

Serhiy Storchaka added the comment: > I think we should focus on fixing the spec for code object equivalents. > Perhaps the test can be simplified to use (co_firstlineno, co_firstrowno, > co_filename). This is not enough if the code was compiled from a string. >>> x = eval('lambda: 1') >>> y

[issue25843] lambdas on the same line may incorrectly share code objects

David MacIver added the comment: Note that 3.x does not correctly handle -0.0, you just have to work a bit harder: >>> (lambda: (-0.0, 0.0), lambda: (0.0, -0.0))[1]() (-0.0, 0.0) -- nosy: +David MacIver ___ Python tracker

[issue25844] Pylauncher, launcher.c: Assigning NULL to a pointer instead of testing against NULL

Roundup Robot added the comment: New changeset 5015440beec2 by Vinay Sajip in branch '3.4': Fixes #25844: Corrected =/== typo potentially leading to crash in launcher. https://hg.python.org/cpython/rev/5015440beec2 New changeset 9552fcd303fd by Vinay Sajip in branch '3.5': Fixes #25844: Correcte

[issue25843] lambdas on the same line may incorrectly share code objects

Serhiy Storchaka added the comment: > The lowest impact fix from a code change would be to add a type equivalence > check for constants as Raymond first suggested, as that only involves adding > an extra check to code_richcompare: > https://hg.python.org/cpython/file/tip/Objects/codeobject.c#l