[issue21435] Segfault in gc with cyclic trash

Andrew Svetlov added the comment: Thanks a lot! The patch fixes crush dump issue with __del__ in aiohttp library tests also. -- nosy: +asvetlov ___ Python tracker ___ ___

[issue14910] argparse: disable abbreviation

Changes by paul j3 : Added file: http://bugs.python.org/file35191/issue14910_2.patch ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue14910] argparse: disable abbreviation

Changes by paul j3 : Removed file: http://bugs.python.org/file35190/issue14910_2.patch ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue14910] argparse: disable abbreviation

paul j3 added the comment: Update the patch - test_argparse.py - cleanup spaces argparse.rst - merging conflicts -- Added file: http://bugs.python.org/file35190/issue14910_2.patch ___ Python tracker __

[issue21332] subprocess bufsize=1 docs are misleading

akira added the comment: I've updated the patch to remove changes to test_universal_newlines test that was fixed in revision 37d0c41ed8ad that closes #21396 issue -- Added file: http://bugs.python.org/file35189/subprocess-line-buffering-issue21332-ps4.patch ___

[issue21455] add default backlog to socket.listen()

Charles-François Natali added the comment: > Is there a risk of SOMAXCONN being huge and therefore allocating a large > amount of resources? On a sensible operating system, no, but better safe than sorry: the patch attached caps the value to 128 (a common SOMAXCONN value). It should be high eno

[issue21435] Segfault in gc with cyclic trash

Changes by Tim Peters : -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker ___ ___ Python-bugs-lis

[issue21435] Segfault in gc with cyclic trash

Roundup Robot added the comment: New changeset 64ba3f2de99c by Tim Peters in branch '3.4': Issue #21435: Segfault in gc with cyclic trash http://hg.python.org/cpython/rev/64ba3f2de99c New changeset cb9a3985df00 by Tim Peters in branch 'default': Merge from 3.4. http://hg.python.org/cpython/rev/c

[issue21396] Python io implementation doesn't flush with write_through=True unlike C implementation

Antoine Pitrou added the comment: Thank you for the patch! -- resolution: -> fixed stage: needs patch -> resolved status: open -> closed ___ Python tracker ___ _

[issue21396] Python io implementation doesn't flush with write_through=True unlike C implementation

Roundup Robot added the comment: New changeset 39f2a78f4357 by Antoine Pitrou in branch '3.4': Issue #21396: Fix TextIOWrapper(..., write_through=True) to not force a flush() on the underlying binary stream. http://hg.python.org/cpython/rev/39f2a78f4357 New changeset 37d0c41ed8ad by Antoine Pit

[issue21037] add an AddressSanitizer build option

Charles-François Natali added the comment: I just pushed the patch. Stefan, did you have time to setup a buildbot? -- ___ Python tracker ___

[issue21396] Python io implementation doesn't flush with write_through=True unlike C implementation

Antoine Pitrou added the comment: Actually, with the patch, the universal_newlines tests in test_subprocess hang (quite logically, since they lack a flush()). I will fix them as well. -- ___ Python tracker ___

[issue21396] Python io implementation doesn't flush with write_through=True unlike C implementation

Antoine Pitrou added the comment: The patch looks basically fine. I will make a few tweaks to the comments in the test case. -- ___ Python tracker ___ __

[issue18564] Integer overflow in socketmodule

Antoine Pitrou added the comment: > I am thinking about patching it there and then open another ticket > here in order to adopt str2ba(). This way we can close this ticket for > now. Well, if some str2ba() versions are notoriously buggy, we should probably not use it, IMHO. -- ___

[issue21455] add default backlog to socket.listen()

Antoine Pitrou added the comment: Is there a risk of SOMAXCONN being huge and therefore allocating a large amount of resources? -- ___ Python tracker ___ ___

[issue21037] add an AddressSanitizer build option

Roundup Robot added the comment: New changeset 17689e43839a by Charles-François Natali in branch 'default': Issue #21037: Add a build option to enable AddressSanitizer support. http://hg.python.org/cpython/rev/17689e43839a -- nosy: +python-dev ___ Pyt

[issue21435] Segfault in gc with cyclic trash

Tim Peters added the comment: finalize42.patch includes a test case. If nobody objects within a few hours, I'll commit it. -- Added file: http://bugs.python.org/file35187/finalize42.patch ___ Python tracker _

[issue21444] __len__ can't return big numbers

Changes by Benjamin Peterson : -- resolution: -> wont fix status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing

[issue21435] Segfault in gc with cyclic trash

Changes by Tim Peters : -- title: Segfault with cyclic reference and asyncio.Future -> Segfault in gc with cyclic trash ___ Python tracker ___ __

[issue21444] __len__ can't return big numbers

Raymond Hettinger added the comment: I recommend this be closed: too much impact on existing code for too little benefit. CPython has historically imposed some artificial implementation specific details in order make the implementation cleaner and faster internally (i.e. a limit on the num

[issue21448] Email Parser use 100% CPU

jader fabiano added the comment: Hi. I undestood this problem that It was happening, I was writting the mime wrong in the attachments. I read a file with size 4M and I've converted to Base64, so I've written in the mime the content. But i wasn't put the lines with 76 ccharacters plus ""/r/n". I w

[issue21435] Segfault with cyclic reference and asyncio.Future

Changes by Tim Peters : -- assignee: -> tim.peters ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mai

[issue21454] asyncio's loop.connect_read_pipe makes pipes non-blocking contrary to the documentation

Guido van Rossum added the comment: Thanks for the report, that should be easy to fix. Regarding PTYs, we're aware: https://code.google.com/p/tulip/issues/detail?id=147 -- nosy: +haypo ___ Python tracker

[issue21455] add default backlog to socket.listen()

New submission from Charles-François Natali: Having to pass an explicit backlog value to listen() is a pain: most people don't know which value to pass, and often end up using a value too small which can lead to connections being rejected. For example, if you search throughout the standard libr

[issue21454] asyncio's loop.connect_read_pipe makes pipes non-blocking contrary to the documentation

New submission from John Isidore: the documentation for BaseEventLoop.connect_read_pipe says: > "pipe is file-like object **already switched** to nonblocking." http://hg.python.org/cpython/file/232938736a31/Doc/library/asyncio-eventloop.rst#l453 But it looks like connect_read_pipe() accepts b

[issue21453] Support of RPM subpackages in distutils

New submission from Vitaly Isaev: RPM Subpackages are very useful when you maintain the big project on the RHEL-kind Linux distro and you need to sparse the project into several differing packages (for instance - , -libs, -devel, -debuginfo). It would be convenient to do the same in a purely P

[issue21350] bug in file.writelines accepting buffers

Changes by Antoine Pitrou : -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker ___ ___ Python-bugs

[issue21350] bug in file.writelines accepting buffers

Roundup Robot added the comment: New changeset db842f730432 by Antoine Pitrou in branch '2.7': Issue #21350: Fix file.writelines() to accept arbitrary buffer objects, as advertised. http://hg.python.org/cpython/rev/db842f730432 -- nosy: +python-dev _

[issue21350] bug in file.writelines accepting buffers

Antoine Pitrou added the comment: Thanks for the report and the patch! For a bit of trivia, this code has been there since 2000 (63ea2a2df06f). -- ___ Python tracker ___ ___

[issue21435] Segfault with cyclic reference and asyncio.Future

Larry Hastings added the comment: I'm totally on board with you guys checking this in for 3.4.1. -- ___ Python tracker ___ ___ Python-

[issue21435] Segfault with cyclic reference and asyncio.Future

Antoine Pitrou added the comment: > finalize4.patch repairs the comment typos, adds a new comment, and > removes the unused `old` argument. I think the code is ready to ship > with this. Thanks! So do I. -- ___ Python tracker

[issue13598] string.Formatter doesn't support empty curly braces "{}"

Armin Ronacher added the comment: Is there any chance this will be fixed for 2.7 as well? -- nosy: +aronacher ___ Python tracker ___ _

[issue21300] Docs (incorrectly) suggest email.policy.default is the default policy

R. David Murray added the comment: That was actually copy and paste of an existing typo, which I've also now fixed. Thanks. -- ___ Python tracker ___ __

[issue21300] Docs (incorrectly) suggest email.policy.default is the default policy

Roundup Robot added the comment: New changeset 9e55089aa505 by R David Murray in branch '3.4': #21300: fix typo http://hg.python.org/cpython/rev/9e55089aa505 New changeset 232938736a31 by R David Murray in branch 'default': Merge #21300: fix typo http://hg.python.org/cpython/rev/232938736a31 --

[issue21452] make_buildinfo.exe with VS2013 fails due ill-formed IntDir path

Tim Golden added the comment: Attached project patch seems to build successfully on VS2010. It's possible that this failed in some way on VS2008; AFAICT it hasn't been touched since Brian first ported it two years ago. Adding Zach Ware for a second opinion. -- nosy: +zach.ware Added f

[issue21300] Docs (incorrectly) suggest email.policy.default is the default policy

Merlijn van Deen added the comment: Small typo that slipped in: 'udpate' instead of 'update' on the following lines: http://hg.python.org/cpython/rev/63fa945119cb#l2.18 http://hg.python.org/cpython/rev/63fa945119cb#l2.43 http://hg.python.org/cpython/rev/63fa945119cb#l2.66 -- _

[issue21452] make_buildinfo.exe with VS2013 fails due ill-formed IntDir path

Mateusz Łoskot added the comment: On 8 May 2014 11:53, Tim Golden wrote: > > What effect does your patch have on a VS2010 build? I don't know. I don't use VS2010. However, I suspect the option 1) fix should be applied anyway as it is suggested by the comment in make_buildinfo.c. Why the pythonc

[issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows

Changes by Kristján Valur Jónsson : -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailin

[issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows

Roundup Robot added the comment: New changeset ab5e2b0fba15 by Kristján Valur Jónsson in branch '3.3': The PyCOND_TIMEDWAIT must use microseconds for the timeout argument http://hg.python.org/cpython/rev/ab5e2b0fba15 New changeset 7764bb7f2983 by Kristján Valur Jónsson in branch '3.4': Merging f

[issue13630] IDLE: Find(ed) text is not highlighted while dialog box is open

Tal Einat added the comment: Thanks for the kind words, Francisco! And also for taking the time to get SearchBar working on Python3 and giving it a try. I agree that SearchBar is a huge improvement over IDLE's simple find and replace dialogs. And by now every potential user is used to such sea

[issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows

Roundup Robot added the comment: New changeset 80b76c6fad44 by Kristján Valur Jónsson in branch 'default': The PyCOND_TIMEDWAIT must use microseconds for the timeout argument http://hg.python.org/cpython/rev/80b76c6fad44 -- nosy: +python-dev ___ Pytho

[issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows

Kristján Valur Jónsson added the comment: nope, let's not do that :) -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsub

[issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows

Tim Golden added the comment: I can confirm that the attached test.py times out after 2150 seconds (ie 30+ minutes) with your (tweaked) patch applied: python test.py 2150 Running Debug|Win32 interpreter... 2014-05-08 10:33:53.670091 Expected to time out by 2014-05-08 11:09:43.670091 Timed Out 2

[issue21452] make_buildinfo.exe with VS2013 fails due ill-formed IntDir path

Tim Golden added the comment: What effect does your patch have on a VS2010 build? VS2010 is the official toolset for current Python 3.x versions so any changes we make must support that. Also: does the same problem occur on the development branch? (De-selecting 3.2 as it's in security-fix mo

[issue12916] Add inspect.splitdoc

Stéphane Wirtel added the comment: Hi all, No news about this issue, Do you have time for a feedback? Thanks -- ___ Python tracker ___

[issue13630] IDLE: Find(ed) text is not highlighted while dialog box is open

Francisco Gracia added the comment: I had problems for installing your *SearchBar*, Tal, in Python 33 and 34 until it downed onto me that in its present form it is only Python 2 compliant. This is then its first weakness, that of course can be easily remedied by applying *2to3.py* to it, as I

[issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows

Kristján Valur Jónsson added the comment: I see, I wasn't able to compile it yesterday when I did it :) -- ___ Python tracker ___ ___

[issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows

Tim Golden added the comment: s/Py_LONG_LONG/PY_LONG_LONG/ -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: h

[issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows

Kristján Valur Jónsson added the comment: Thanks. Can you confirm that it resolves the issue? I'll get it checked in once I get the regrtest suite run. -- ___ Python tracker _

[issue21452] make_buildinfo.exe with VS2013 fails due ill-formed IntDir path

New submission from Mateusz Loskot: While building Python 3.2 or Python 3.4 with Visual Studio 2013 on Windows 8.1, pythoncore.vcxproj fails to build due to illformed pre-link event command. (FYI, I have upgraded all .vcxproj files to VS2013 locally.) Here is the command and the error: 1>PreL

[issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows

Tim Golden added the comment: +1 for Kristjan's latest patch. And thanks for working this through, Kristjan: I'd missed the fact that the microseconds conversion could itself overflow even an unsigned long. -- ___ Python tracker