[issue34395] memory leaks in error handling in csv and pickle modules

Serhiy Storchaka added the comment: New changeset ae1f0127298b1193618062fd0c8a3b434656e780 by Serhiy Storchaka (Sergey Fedoseev) in branch '2.7': bpo-34395: Fix memory leaks caused by incautious usage of PyMem_Realloc(). (GH-8785)

[issue6700] inspect.getsource() returns incorrect source lines at the module level

Change by Aivar Annamaa : -- title: inspect.getsource() returns incorrect source lines -> inspect.getsource() returns incorrect source lines at the module level versions: +Python 3.6, Python 3.7 ___ Python tracker

[issue6700] inspect.getsource() returns incorrect source lines

Change by Aivar Annamaa : -- nosy: +Aivar.Annamaa ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24218] Also support SMTPUTF8 in smtplib's send_message method.

Jens Troeger added the comment: Thanks David: PR on Github (which is R/O) or where should I submit to? -- ___ Python tracker ___

[issue34410] Segfault/TimeoutError: itertools.tee of multiprocessing.pool.imap_unordered

Carlo Rosati added the comment: `for i in itertools.count()` in the first implementation I posted should be `while True`. I was using that for debugging. -- ___ Python tracker

[issue34410] Segfault/TimeoutError: itertools.tee of multiprocessing.pool.imap_unordered

Carlo Rosati added the comment: I've actually written a few workarounds that should be considered a multiprocessing specific tee function. I need feedback/critique on these. Hopefully we can all agree on one solution that's the best. It is unfortunate that the multiprocessing manager does

[issue34416] PyCapsule_Import seems to release the GIL without acquiring it

Pablo Galindo Salgado added the comment: Summary of how I see this dump: 1) Thread 2 tries to get the GIL. 2) Thread 3 tries to get the GIL. 3 Gil acquired! (0) 4) Thread 2 drops the GIL, which means that thread 2 managed to get it before. 5) Gil acquired! (1) 6) Thread 2 tries to get the

[issue34414] Absolute imports conflict with local files

Eric V. Smith added the comment: See https://docs.python.org/3/tutorial/modules.html#the-module-search-path Calling this a "hack", and "crazy", is not the way to get volunteers to help you with your issue. Please show a little more tolerance, please. -- nosy: +eric.smith

[issue34217] windows: cross compilation fails due to headers with uppercase

Steve Dower added the comment: > The current situation is that 100% of the windows includes are lowercase and > allow cross compilation. Please be precise with what you are saying - the "current situation" is only so because you proposed changes and got them merged without proper

[issue34416] PyCapsule_Import seems to release the GIL without acquiring it

Change by Pablo Galindo Salgado : -- Removed message: https://bugs.python.org/msg323627 ___ Python tracker ___ ___ Python-bugs-list

[issue34416] PyCapsule_Import seems to release the GIL without acquiring it

Pablo Galindo Salgado added the comment: Breaking in take_gil and drop_gil I get this trace: Thread 2 "gil" hit Breakpoint 1, 0x5559563d in acquire_gil () Thread 3 "gil" hit Breakpoint 1, 0x5559563d in acquire_gil () Waiting for GIL (0) Waiting for GIL (1) Thread 2 "gil" hit

[issue34416] PyCapsule_Import seems to release the GIL without acquiring it

Pablo Galindo Salgado added the comment: Breaking in take_gil and drop_gil I get this trace: Thread 2 "gil" hit Breakpoint 1, 0x5559563d in acquire_gil () Thread 3 "gil" hit Breakpoint 1, 0x5559563d in acquire_gil () Waiting for GIL (0) Waiting for GIL (1) Thread 2 "gil" hit

[issue20849] add exist_ok to shutil.copytree

Giampaolo Rodola' added the comment: I think this feature request is reasonable for 2 reasons: 1) As it stands if dst directory exists copytree() cannot be used. The only possible workaround is using rmtree(dst) first, but that doesn't seem to make much sense. The change may look extremely

[issue34217] windows: cross compilation fails due to headers with uppercase

Erik Janssens added the comment: As I understand it, if mingw-w64 would change to camelcase headers, it would break backwards compatibility, since a lot of windows source code uses file names in includes that differ from those on this, which works in MSVC, so it goes unnoticed. There is no

[issue34416] PyCapsule_Import seems to release the GIL without acquiring it

Paul Ganssle added the comment: Using a modified version of Python 3.7.0 that prints "Releasing GIL" whenever PyGILState_Release, I get this: Waiting for GIL (0) Gil acquired! (0) Waiting for GIL (1) Gil acquired! (1) Releasing GIL Gil released! (0) Releasing GIL Gil released! (1) So

[issue8478] tokenize.untokenize first token missing failure case

Change by Berker Peksag : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue34417] imp.find_module reacts badly to iterator

New submission from Phillip M. Feldman : `imp.find_module` goes down in flames if one tries to pass an iterator rather than a list of folders. Firstly, the message that it produces is somewhat misleading: RuntimeError: sys.path must be a list of directory names Secondly, it would be

[issue34217] windows: cross compilation fails due to headers with uppercase

Steve Dower added the comment: Have you posted to their mailing list to ask why they use different casing from the official SDK and whether they would consider supporting both (via symlink, presumably)? I think it would be strange for CPython to add a style rule for a non-supported

[issue34416] PyCapsule_Import seems to release the GIL without acquiring it

Change by Eric N. Vander Weele : -- nosy: +ericvw ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34217] windows: cross compilation fails due to headers with uppercase

Erik Janssens added the comment: The lowercase headers are indeed part of the mingw-w64 SDK, which is the most convenient option to cross compile on a linux host for a windows target. -- ___ Python tracker

[issue34416] PyCapsule_Import seems to release the GIL without acquiring it

New submission from Paul Ganssle : I was recently debugging some multithreaded Rust code that was deadlocking, and I tracked it down to what I'm fairly certain is a bug somewhere in PyCapsule_Import, where it seems that PyCapsule_Import releases the GIL without first acquiring it. I've

[issue34217] windows: cross compilation fails due to headers with uppercase

Eryk Sun added the comment: > New windows will support case sensitive filesystem too. NTFS in Windows 10 supports a flag to mark a directory as case sensitive [*] via NtSetInformationFile: FileCaseSensitiveInformation, which can be set from the command line via fsutil.exe. In recent builds

[issue34415] Typo in logging.Formatter docstring

New submission from Semyon : There is a typo in the docstring for logging.Formatter: > default value of "%s(message)\\n" is used. I am sure it should be different (and in sync with the actual value): > default value of "%(message)s\\n" is used. The problem is in py2.7, py3.7 and most likely

[issue34391] test_ftplib is failing with TLS 1.3

Christian Heimes added the comment: New changeset 2ec530cd5537dfda5ca0af6ac696e45013ed31d2 by Christian Heimes in branch '2.7': [2.7] bpo-34391: Fix ftplib test for TLS 1.3 (GH-8787) (GH-8791) https://github.com/python/cpython/commit/2ec530cd5537dfda5ca0af6ac696e45013ed31d2 --

[issue34391] test_ftplib is failing with TLS 1.3

Christian Heimes added the comment: New changeset 870247a57e84ccaa3f6a6ce955f4168632b967a8 by Christian Heimes (Miss Islington (bot)) in branch '3.7': [3.7] bpo-34391: Fix ftplib test for TLS 1.3 (GH-8787) (GH-8789)

[issue34391] test_ftplib is failing with TLS 1.3

Christian Heimes added the comment: New changeset cabe916dc694997d4892b58986e73a713d5a2f8d by Christian Heimes (Miss Islington (bot)) in branch '3.6': [3.6] bpo-34391: Fix ftplib test for TLS 1.3 (GH-8787) (#8790)

[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

Michael Felt added the comment: On 16/08/2018 17:34, Ronald Oussoren wrote: > Ronald Oussoren added the comment: > > I don't understand this clarification: > >> Clarification: while Mac/OS falls under "posix" in python terms - maybe >> "breakage" will need to be accepted, >> or, for

[issue20849] add exist_ok to shutil.copytree

Change by Joshua Bronson : -- pull_requests: +8266 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34410] Segfault/TimeoutError: itertools.tee of multiprocessing.pool.imap_unordered

Raymond Hettinger added the comment: Davin, is there anything itertools.tee() can do about this or is this a multiprocessing issue? -- nosy: +davin, rhettinger ___ Python tracker

[issue34391] test_ftplib is failing with TLS 1.3

Change by Christian Heimes : -- pull_requests: +8265 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34391] test_ftplib is failing with TLS 1.3

Change by miss-islington : -- pull_requests: +8264 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34391] test_ftplib is failing with TLS 1.3

Change by miss-islington : -- pull_requests: +8263 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34391] test_ftplib is failing with TLS 1.3

Christian Heimes added the comment: New changeset 1590c393360df059160145e7475754427bfc6680 by Christian Heimes in branch 'master': bpo-34391: Fix ftplib test for TLS 1.3 (GH-8787) https://github.com/python/cpython/commit/1590c393360df059160145e7475754427bfc6680 --

[issue34414] Absolute imports conflict with local files

Jonathan Hadida added the comment: Thank you for your quick reply. How can this be expected behaviour? Could I please kindly ask you to point to an documented explanation, specifically for why the folder is PREpended to sys.path (put before), instead of being APpended (put after). The fact

[issue34395] memory leaks in error handling in csv and pickle modules

Change by Sergey Fedoseev : -- pull_requests: +8262 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34414] Absolute imports conflict with local files

Ronald Oussoren added the comment: This is expected behaviour: When your run a script the directory containing the script is added to the start of sys.path. Running "python3.6 a/foo.py" therefore adds "a" to the start of sys.path, and "math.py" then shadows the stdlib module "math". This

[issue34391] test_ftplib is failing with TLS 1.3

Change by Christian Heimes : -- keywords: +patch pull_requests: +8261 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue34414] Absolute imports conflict with local files

New submission from Jonathan Hadida : This submission follows a post on StackOverflow: https://stackoverflow.com/q/51878397/472610 I have reproduced the unexpected behaviour with multiple python versions, either with a Homebrew install, or using Anaconda/Miniconda. Note that comments to the

[issue34391] test_ftplib is failing with TLS 1.3

Christian Heimes added the comment: The "OSError: [Errno 0] Error" failures are caused by session ticket handling in two way shutdown. I reported the issue a while ago https://github.com/openssl/openssl/issues/6262 and it's fixed in OpenSSL git master (to be released as 1.1.1-pre9). The

[issue33216] [3.5] Wrong order of stack for CALL_FUNCTION_VAR and CALL_FUNCTION_VAR_KW

Eric Snow added the comment: FYI, I opened bpo-34413 to address how the bytecode change is not mentioned in the porting section of the 3.5 "What's New" doc. In retrospect (I didn't notice that this issue was still open), I suppose that doesn't need a separate issue so feel free to close

[issue33216] [3.5] Wrong order of stack for CALL_FUNCTION_VAR and CALL_FUNCTION_VAR_KW

Eric Snow added the comment: FTR, the change was introduced by the PEP 448 implementation. [1] [1] https://github.com/python/cpython/pull/8338#issuecomment-406256152 -- nosy: +eric.snow ___ Python tracker

[issue34413] Porting section of 3.5 "What's New" doc does not mention bytecode changes.

New submission from Eric Snow : In the 3.5 "What's New" doc, the porting section [1] does not mention the bytecode changes resulting from the PEP 448 implementation. [2][3] It should. I've marked this issue for the versions past 3.5 because each branch has its own "What's New" doc for 3.5.

[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

Ronald Oussoren added the comment: I don't understand this clarification: > Clarification: while Mac/OS falls under "posix" in python terms - maybe > "breakage" will need to be accepted, > or, for "back-ports" Mac/OS will be "as if root or super-user" and use > an additional (optional)

[issue34217] windows: cross compilation fails due to headers with uppercase

Steve Dower added the comment: > whatever might be the 'right' solution, it's always an advantage to > have a consistent codebase. Not when you are consistently wrong, it's not. Let's figure out the right answer here before making many changes to the codebase. First, can you tell me where

[issue34217] windows: cross compilation fails due to headers with uppercase

Steve Dower added the comment: > Stop relying to case insensitive filesystem makes sense to me. If this is the case, then we need to normalise the casing to match the actual files (which are mixed-case, not lowercase). You just broke this with your PR :) So which is it? Do we match the

[issue34412] strsignal(3) does not exist on HP-UX

Change by Michael Osipov <1983-01...@gmx.net>: -- keywords: +patch pull_requests: +8259 stage: -> patch review ___ Python tracker ___

[issue34412] strsignal(3) does not exist on HP-UX

Michael Osipov <1983-01...@gmx.net> added the comment: References: * https://github.com/google/cmockery/issues/11 * https://www.spinics.net/lists/dash/msg00547.html -- ___ Python tracker

[issue34412] strsignal(3) does not exist on HP-UX

New submission from Michael Osipov <1983-01...@gmx.net>: HP-UX does not provide any mappings from signals to strings. The proper approach is to map just like for Windows. Alternatively, one could simply return the singal as an int. -- components: Library (Lib) messages: 323600 nosy:

[issue34401] [SOLUTION] Make test_gdb work on HP-UX

Change by Michael Osipov <1983-01...@gmx.net>: Removed file: https://bugs.python.org/file47749/test_gdb.patch ___ Python tracker ___ ___

[issue34395] memory leaks in error handling in csv and pickle modules

Change by Sergey Fedoseev : -- pull_requests: +8258 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34246] Gentoo Refleaks 3.7: test_smtplib has dangling threads

Change by Serhiy Storchaka : -- components: +email nosy: +barry ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue33216] [3.5] Wrong order of stack for CALL_FUNCTION_VAR and CALL_FUNCTION_VAR_KW

Change by Serhiy Storchaka : -- pull_requests: +8257 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33216] [3.5] Wrong order of stack for CALL_FUNCTION_VAR and CALL_FUNCTION_VAR_KW

Change by Serhiy Storchaka : -- pull_requests: +8256 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue27435] ctypes library loading and AIX - also for 2.7.X (and later)

Michael Felt added the comment: as this is not (likely) to be backported to Python2 (by python, fyi: I do include full ctypes-load_library() support in my "independent" packaging) and it is "resolved" for Python3-3.7 issue26439 this issue may, imho, be closed. --

[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

Michael Felt added the comment: I want to believe this can be resolved - without breakage on POSIX. Clarification: while Mac/OS falls under "posix" in python terms - maybe "breakage" will need to be accepted, or, for "back-ports" Mac/OS will be "as if root or super-user" and use an additional

[issue34217] windows: cross compilation fails due to headers with uppercase

miss-islington added the comment: New changeset bf8e9d18dd75f58ce3b9761763ae10c0800b43d8 by Miss Islington (bot) in branch '3.7': bpo-34217: Use lowercase for windows headers (GH-8472) https://github.com/python/cpython/commit/bf8e9d18dd75f58ce3b9761763ae10c0800b43d8 --

[issue34217] windows: cross compilation fails due to headers with uppercase

INADA Naoki added the comment: New windows will support case sensitive filesystem too. Stop relying to case insensitive filesystem makes sense to me. -- ___ Python tracker

[issue34217] windows: cross compilation fails due to headers with uppercase

Erik Janssens added the comment: @inada.naoki : thank you ! @steve.dower : I would not consider those bugs per se, but they are inconsistencies, for example in the master branch : number of "Windows.h" includes : 2 number of "windows.h" includes : 55 whatever might be the 'right' solution,

[issue34217] windows: cross compilation fails due to headers with uppercase

Change by miss-islington : -- pull_requests: +8255 stage: resolved -> patch review ___ Python tracker ___ ___ Python-bugs-list

[issue34217] windows: cross compilation fails due to headers with uppercase

INADA Naoki added the comment: New changeset e6a4755e6793942b950c1595e0c34bd66a0ee13e by INADA Naoki (Erik Janssens) in branch 'master': bpo-34217: Use lowercase for windows headers (GH-8472) https://github.com/python/cpython/commit/e6a4755e6793942b950c1595e0c34bd66a0ee13e --

[issue1529353] Squeezer - squeeze large output in IDLE's shell

Change by Tal Einat : -- title: Squeezer - squeeze large output in IDLE -> Squeezer - squeeze large output in IDLE's shell ___ Python tracker ___