[issue29564] ResourceWarning tracking is attaching incorrect file:position to unclosed socket

STINNER Victor added the comment: The report issue is not a bug. By design, Python cannot emits the ResourceWarning warning where you expect that it should be emitted. Martin explained you the thing with reference counter, reference cycles and the garbage collector. It is exactly *why* I impl

[issue29564] ResourceWarning tracking is attaching incorrect file:position to unclosed socket

Martin Panter added the comment: You say that the line number is incorrect. What would you consider a correct line number to be? Let me try again to explain my theory about garbage collection and reference cycles. Perhaps you have two objects a and b, linked such that a.x = b and b.y = a. Thi

[issue29553] Argparser does not display closing parentheses in nested mutex groups

Andrew Nester added the comment: I've just added PR fixing this. -- nosy: +andrewnester ___ Python tracker ___ ___ Python-bugs-list ma

[issue29553] Argparser does not display closing parentheses in nested mutex groups

Changes by Andrew Nester : -- pull_requests: +76 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue29548] Recommend PyObject_Call* APIs over PyEval_Call*() APIs

STINNER Victor added the comment: "I think first at all PyEval_Call* functions should be documented (issue11165). The documentation should recommend to use corresponding PyObject_Call* functions (...)" I *now* agree :-) -- title: Recommend PyObject_Call* APIs over PyEval_Call*() APIs -

[issue11165] Document PyEval_Call* functions

INADA Naoki added the comment: In PR 75, I added a comment in Include/ceval.h, right before PyEval_Call* APIs. https://github.com/python/cpython/pull/75/files#diff-da3df9def5eca3595399b0a5a7698eac -- ___ Python tracker

[issue11165] Document PyEval_Call* functions

Serhiy Storchaka added the comment: While they are undocumented there is no a place for adding the recommendation of using corresponding PyObject_Call* functions and describing the way of porting from PyEval_Call* functions to PyObject_Call* functions. -- nosy: +serhiy.storchaka _

[issue11165] Document PyEval_Call* functions

INADA Naoki added the comment: I think PyObject_Call* APIs should be preferred. As discussed in #29548, we can't remove or deprecate PyEval_Call*. But I don't think it's worth enough to document them. How about keep them undocumented? -- nosy: +inada.naoki _

[issue29548] Recommend PyObject_Call* APIs over PyEval_Call*() APIs

Serhiy Storchaka added the comment: I think first at all PyEval_Call* functions should be documented (issue11165). The documentation should recommend to use corresponding PyObject_Call* functions and explicitly describe the difference between PyEval_Call* and PyObject_Call* APIs. Few releases

[issue29548] Recommend PyObject_Call* APIs over PyEval_Call*() APIs

INADA Naoki added the comment: I've stopped to deprecating. changed issue title. -- title: deprecate PyEval_Call*() functions. -> Recommend PyObject_Call* APIs over PyEval_Call*() APIs ___ Python tracker ___

[issue29532] functools.partial is not compatible between 2.7 and 3.5

Raymond Hettinger added the comment: Agree that this is a bug. Patch and test looks good. -- nosy: +rhettinger ___ Python tracker ___ ___

[issue29565] Still broken ctypes calling convention on MSVC / 64-bit Windows (large structs)

New submission from Igor Kudrin: It looks like resolving https://bugs.python.org/issue20160 didn't fix all the issues. When a large struct is used as a parameter, a reference to the object itself is passed to the function, not a reference to a temporary copy, as it is required in https://msdn.

[issue29564] ResourceWarning tracking is attaching incorrect file:position to unclosed socket

David Ford (FirefighterBlu3) added the comment: i do know what's causing it, it's the twilio module not cleanly finishing up. i pointed out my call to this in the initial description. /usr/lib/python3.6/site-packages/httplib2/__init__.py:857: DeprecationWarning: key_file, cert_file and check_h

[issue29548] deprecate PyEval_Call*() functions.

Raymond Hettinger added the comment: In general, we should have a strong aversion to deprecation except in cases where something is actually broken. API changes make it more difficult for people to migrate to Python 3 or to upgrade between minor releases. The longer an API has existed, the

[issue29557] binhex documentation claims unknown bug

Raymond Hettinger added the comment: Georg, do remember why this admonition was present? -- nosy: +georg.brandl, rhettinger ___ Python tracker ___ ___

[issue29540] Add compact=True flag to json.dump/dumps

Raymond Hettinger added the comment: Everyone can chime in with their thoughts, but Bob gets to make the decision on this one. -- ___ Python tracker ___

[issue29355] sqlite3: remove sqlite3_stmt_readonly()

Changes by Palm Kevin : -- nosy: +palm.kevin ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue29225] distutils.command.install_lib.get_outputs() wrong with extensions built inplace

Elvis Stansvik added the comment: It's been over a month. It would be great if someone could at least acknowledge the bug. The current behavior is clearly wrong. I realize changes to distutils is perhaps not the most fun thing to review, but I'd like some kind of fix for this to go in. I have

[issue29536] test_hashlib failure on Ubuntu 16.04

Martin Panter added the comment: Looks like the tests should run if the data is already downloaded. First run needs -u urlfetch. My guess is your data is somehow corrupted. Check out your copy of the files in Lib/test/data/, compare them to e.g. .

<    1   2