[issue37221] PyCode_New API change breaks backwards compatibility policy
Jeroen Demeyer added the comment: Technically, tp_print was replaced by tp_vectorcall_offset. But that doesn't answer the question how we should deal with tp_print backwards compatibility. Cython does FooType.tp_print = 0; With this in mind, simply replacing tp_print by tp_vectorcall_offset is unsafe as it would break types that actually use vectorcall (there aren't many for now, but who knows how this will change in the future). It would be safer to replace tp_print by tp_vectorcall since setting that to 0 won't break anything (neither for now, nor when PR 13930 is merged). -- ___ Python tracker <https://bugs.python.org/issue37221> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37221] PyCode_New API change breaks backwards compatibility policy
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +13873 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/14009 ___ Python tracker <https://bugs.python.org/issue37221> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37221] PyCode_New API change breaks backwards compatibility policy
Jeroen Demeyer added the comment: PR 14009 deals with tp_print -- ___ Python tracker <https://bugs.python.org/issue37221> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37247] swap distutils build_ext and build_py commands to allow proper SWIG extension installation
Jeroen Demeyer added the comment: > SWIG creates the files correctly in the build_ext command One could argue that running SWIG should be an entirely different step, not part of build_ext. I'm afraid that your idea of swapping build_ext and build_py will be rejected because it has a high chance of breaking stuff: we have always done build_py before build_ext and packages probably rely on this order. -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue37247> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37221] PyCode_New API change breaks backwards compatibility policy
Jeroen Demeyer added the comment: I think that the PyCode_New() compatibility problem and tp_print are sufficiently closely related that they can be discussed together. In any case, I agree that it makes little sense to fix just one. -- ___ Python tracker <https://bugs.python.org/issue37221> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26110] Speedup method calls 1.2x
Jeroen Demeyer added the comment: Note that this idea has been generalized by PEP 590: any type can support this optimization by setting the Py_TPFLAGS_METHOD_DESCRIPTOR flag. -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue26110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37249] Missing declaration of _PyObject_GetMethod
New submission from Jeroen Demeyer : The function _PyObject_GetMethod is internal and private, but it should still be declared properly. Currently, it is "manually" declared in two .c files where it's used. -- components: Interpreter Core messages: 345336 nosy: jdemeyer priority: normal severity: normal status: open title: Missing declaration of _PyObject_GetMethod versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue37249> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37249] Missing declaration of _PyObject_GetMethod
Change by Jeroen Demeyer : -- nosy: +yselivanov ___ Python tracker <https://bugs.python.org/issue37249> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37249] Missing declaration of _PyObject_GetMethod
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +13879 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14015 ___ Python tracker <https://bugs.python.org/issue37249> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37250] C files generated by Cython set tp_print to NULL
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +13880 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14009 ___ Python tracker <https://bugs.python.org/issue37250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset
Jeroen Demeyer added the comment: Actually, Cython generates code setting tp_print to 0 (not NULL). -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue37250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset
Jeroen Demeyer added the comment: > If -Werror is used, "type->tp_vectorcall = NULL;" would fail with a > compilation error, since NULL is not exactly an integer, no? No because tp_vectorcall is a function pointer. You're confusing with tp_vectorcall_offset which is an integer. -- ___ Python tracker <https://bugs.python.org/issue37250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset
Jeroen Demeyer added the comment: > I understand that tp_vectorcall_offset=0 is fine and the expected value for a > type which doesn't have the flag _Py_TPFLAGS_HAVE_VECTORCALL. Not necessarily. There are subtleties involved when subclassing: there are cases where tp_vectorcall_offset needs to be non-zero despite _Py_TPFLAGS_HAVE_VECTORCALL not being set. See also PR 13858. -- ___ Python tracker <https://bugs.python.org/issue37250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset
Jeroen Demeyer added the comment: > IMHO the simplest and safest option for this issue is to revert tp_print > removal and move tp_vectorcall_offset at the end of PyTypeObject. That's a drastic solution to a rather simple problem. PR 14009 would fix Cython just fine. -- ___ Python tracker <https://bugs.python.org/issue37250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset
Jeroen Demeyer added the comment: > This code can cause subtle and annoying issue if PR 13858 is merged. I don't see how this is related to PR 13858 at all. Please explain. -- ___ Python tracker <https://bugs.python.org/issue37250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset
Jeroen Demeyer added the comment: > If we decide to not reintroduce tp_print, tp_print removal must be documented > at: https://docs.python.org/dev/whatsnew/3.8.html#changes-in-the-c-api I'll add that to PR 13844. -- ___ Python tracker <https://bugs.python.org/issue37250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset
Jeroen Demeyer added the comment: > This code can cause subtle and annoying issue if PR 13858 is merged. Or maybe you're confusing tp_vectorcall_offset and tp_vectorcall again? -- ___ Python tracker <https://bugs.python.org/issue37250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset
Jeroen Demeyer added the comment: > Honestly, reintroducing tp_print looks simple and safe enough. Is there any > drawback? 1. The one-time effort to change the code and documentation back. 2. Stefan Behnel wanted to use tp_print for backporting vectorcall in Cython to earlier Python versions. 3. Stable ABI incompatibility (the complaint that you incorrectly added to PR 13858 would become correct). -- ___ Python tracker <https://bugs.python.org/issue37250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset
Jeroen Demeyer added the comment: > The two are related, no? Related in the same way that tp_dictoffset and tp_dict are related (i.e. not that much). -- ___ Python tracker <https://bugs.python.org/issue37250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset
Jeroen Demeyer added the comment: > This is a terrible idea, FWIW. Please don't do this. Why not? It's a simple pragmatic solution that fixes an actual problem at essentially no cost to CPython. You're right of course that Cython shouldn't set tp_print to 0 on Python 3. But I don't think that's a relevant argument. -- ___ Python tracker <https://bugs.python.org/issue37250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37247] swap distutils build_ext and build_py commands to allow proper SWIG extension installation
Jeroen Demeyer added the comment: > I would argue the sequence doesn't really matter that much for non SWIG > packages I don't think that this is correct. Or at least, it's not obvious to me that this is correct. It's not uncommon for projects to extend distutils in various ways and the proposed change may break those packages. Adding a separate build step for SWIG (then the order would be build_swig, build_py, build_ext) would be safer and IMHO also more logical. -- ___ Python tracker <https://bugs.python.org/issue37247> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26180] multiprocessing.util._afterfork_registry leak in threaded environment
Jeroen Demeyer added the comment: Why is it that __init__ is called multiple times? I'm just wondering if we could somehow ensure that __init__ is called only once. -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue26180> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28805] Add documentation for METH_FASTCALL and _PyObject_FastCall*()
Jeroen Demeyer added the comment: Victor, of the four functions you mentioned: - _PyObject_FastCallDict: documented by PEP 590 - _PyObject_FastCallKeywords: renamed _PyObject_Vectorcall and documented by PEP 590 - _PyObject_FastCall: not sure if it's useful enough (just use _PyObject_Vectorcall with kwnames=NULL) - _PyObject_CallNoArg: see #37194 So that leaves documenting METH_FASTCALL. -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue28805> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28805] Add documentation for METH_FASTCALL and _PyObject_FastCall*()
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +13938 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/14079 ___ Python tracker <https://bugs.python.org/issue28805> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37231] Optimize calling special methods
Change by Jeroen Demeyer : -- pull_requests: +13996 pull_request: https://github.com/python/cpython/pull/14153 ___ Python tracker <https://bugs.python.org/issue37231> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset
Change by Jeroen Demeyer : -- pull_requests: +14030 pull_request: https://github.com/python/cpython/pull/14193 ___ Python tracker <https://bugs.python.org/issue37250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset
Jeroen Demeyer added the comment: > IMHO the simplest and safest option for this issue is to revert tp_print > removal and move tp_vectorcall_offset at the end of PyTypeObject. I just realized that there is a much simpler solution: add back tp_print at the *end* of the PyTypeObject structure. This will fix the Cython problem and is even less likely to break stuff. I'm doing that in PR 14193. -- ___ Python tracker <https://bugs.python.org/issue37250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37250] C files generated by Cython set tp_print to 0: PyTypeObject.tp_print removed
Change by Jeroen Demeyer : -- title: C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset -> C files generated by Cython set tp_print to 0: PyTypeObject.tp_print removed ___ Python tracker <https://bugs.python.org/issue37250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37250] C files generated by Cython set tp_print to 0: PyTypeObject.tp_print removed
Jeroen Demeyer added the comment: > If we reintroduce it, why not put it back at its previous place, to provide > ABI compatibility? First of all, we longer care about ABI compatibility of PyTypeObject. Second, it is extremely unlikely that the class will use vectorcall: the only way would be to inherit from a base class that uses vectorcall, but there aren't any subclassable classes using vectorcall in CPython. If the class doesn't use vectorcall, then it really doesn't matter: tp_vectorcall_offset is unused in that case, just like tp_print. -- ___ Python tracker <https://bugs.python.org/issue37250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37151] Calling code cleanup after PEP 590
Jeroen Demeyer added the comment: All PRs currently on this issue have been merged, but this is not finished yet. I'm mainly waiting for a resolution on PR 13781 because that's a big change which needs to be done before further cleanup. -- ___ Python tracker <https://bugs.python.org/issue37151> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37233] Use _PY_FASTCALL_SMALL_STACK for method_vectorcall
Change by Jeroen Demeyer : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue37233> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37250] C files generated by Cython set tp_print to 0: PyTypeObject.tp_print removed
Jeroen Demeyer added the comment: > Oh? In that case, let's just remove the reserved/deprecated field :) Don't confuse *ABI* and *API* compatibility. For *API* compatibility, it doesn't matter where we put tp_print. -- ___ Python tracker <https://bugs.python.org/issue37250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37250] C files generated by Cython set tp_print to 0: PyTypeObject.tp_print removed
Jeroen Demeyer added the comment: I would argue for the pragmatic solution: PR 14193 fixes that old Cython-generated code. More generally, it fixes API compatibility and doesn't make ABI compatibility worse than the status quo (the proposal of putting back tp_print in place of tp_vectorcall_offset does). Of course, it may not fix every single use case, but even if we can't fix that hypothetical 0.1%, we can still fix the 99.9%. The proposed fix is very small and only applied to 3.8, so there is no long-term maintenance burden. So the obvious question: why not? What's wrong with PR 14193? -- ___ Python tracker <https://bugs.python.org/issue37250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37250] C files generated by Cython set tp_print to 0: PyTypeObject.tp_print removed
Jeroen Demeyer added the comment: Personally, I don't think that your "read of it" in #msg345990 is relevant to the discussion of the PR (I don't mean this in a bad way). It's one thing to say "we're not obliged to fix this" (I agree with that) but that doesn't imply that it's forbidden to fix the issue and that we should automatically reject proposed fixes. -- ___ Python tracker <https://bugs.python.org/issue37250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37337] Add _PyObject_VectorcallMethod() function
New submission from Jeroen Demeyer : To augment the various PyObject_CallMethod...() functions, we add _PyObject_VectorcallMethod() which uses the vectorcall calling convention. To be consistent with the other vectorcall functions, this function is provisional for now. For efficiency, the "self" argument is NOT passed as separate argument but as part of the usual args array. In other words, the call looks like an unbound method call. I am also adding _PyObject_VectorcallMethodId() taking a _Py_Identifier* as argument and convenience functions PyObject_CallMethodNoArgs() and _PyObject_CallMethodIdNoArgs(), analogous to the recently added PyObject_CallNoArgs(). -- messages: 346032 nosy: Mark.Shannon, inada.naoki, jdemeyer, petr.viktorin, vstinner priority: normal severity: normal status: open title: Add _PyObject_VectorcallMethod() function ___ Python tracker <https://bugs.python.org/issue37337> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37337] Add _PyObject_VectorcallMethod() function
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +14064 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14228 ___ Python tracker <https://bugs.python.org/issue37337> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37340] remove free_list for bound method objects
Jeroen Demeyer added the comment: > I will run pyperformance again after bpo-37337 is merged. Good idea. bpo-37337 removes many calls of _PyObject_CallMethodId() which does NOT use the LOAD_METHOD optimization. -- ___ Python tracker <https://bugs.python.org/issue37340> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37340] remove free_list for bound method objects
Jeroen Demeyer added the comment: > GH-14232 uses only one free object instead of at most 256 free list. That sounds like a compromise which is worse than either extreme: it's worse than no free list because you still have the overhead of dealing with the one object. And it's worse than a free list of 256 because it won't for nested calls. -- ___ Python tracker <https://bugs.python.org/issue37340> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37340] remove free_list for bound method objects
Jeroen Demeyer added the comment: Are the benchmark results that you posted above for removing the free list completely or for the one-element free list as in PR 14232? -- ___ Python tracker <https://bugs.python.org/issue37340> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36231] no "proper" header files on macOS 10.14 Mojave
Change by Jeroen Demeyer : -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue36231> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37250] C files generated by Cython set tp_print to 0: PyTypeObject.tp_print removed
Jeroen Demeyer added the comment: > If we should put in the workaround for 3.8, how does that make it okay to > remove in 3.9? I can easily change my PR to keep it in 3.9, no problem. Nick, what do you think? > put the new field at the end and leave the deprecated one exactly as it was. Can you give a least an argument of why that's better than putting back tp_print at the end? I gave 3 why that's NOT a good idea: msg345357 -- ___ Python tracker <https://bugs.python.org/issue37250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37250] C files generated by Cython set tp_print to 0: PyTypeObject.tp_print removed
Jeroen Demeyer added the comment: > If compatibility is the concern here, then we should be aiming for the > smallest diff between 3.7 and 3.8 I challenge that assertion. The smallest diff may superficially look like the best solution, but on closer inspection, it is not. It will break ABI compatibility in any case where vectorcall is used, while my proposal of putting tp_print at the end does not. What you propose is *worse* than the status quo. -- ___ Python tracker <https://bugs.python.org/issue37250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37250] C files generated by Cython set tp_print to 0: PyTypeObject.tp_print removed
Jeroen Demeyer added the comment: > We haven't released vectorcall yet, so it has no compatibility baseline. I'm talking about the "extremely unlikely" scenario mentioned earlier: a class compiled with 3.7 could subclass a class compiled with 3.8 which uses vectorcall. -- ___ Python tracker <https://bugs.python.org/issue37250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37250] C files generated by Cython set tp_print to 0: PyTypeObject.tp_print removed
Jeroen Demeyer added the comment: > This isn't a supported scenario though. Of course it's not! I was trying to tell you that already in msg345969 but you insisted in msg345988 that we should support that anyway. -- ___ Python tracker <https://bugs.python.org/issue37250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37250] C files generated by Cython set tp_print to 0: PyTypeObject.tp_print removed
Jeroen Demeyer added the comment: The fact that tp_vectorcall_offset replaces tp_print was a very conscious decision that we made already when designing the PEPs (both PEP 580 and PEP 590). We shouldn't just throw that away without a good reason. So far I haven't seen any good reason, only an unsubstantiated claim that it is supposedly more backwards compatible to put tp_vectorcall_offset at the end. -- ___ Python tracker <https://bugs.python.org/issue37250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37337] Add _PyObject_VectorcallMethod() function
Change by Jeroen Demeyer : -- pull_requests: +14093 pull_request: https://github.com/python/cpython/pull/14267 ___ Python tracker <https://bugs.python.org/issue37337> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37151] Calling code cleanup after PEP 590
Change by Jeroen Demeyer : -- pull_requests: +14095 pull_request: https://github.com/python/cpython/pull/14269 ___ Python tracker <https://bugs.python.org/issue37151> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37221] PyCode_New API change breaks backwards compatibility policy
Change by Jeroen Demeyer : -- pull_requests: -13873 ___ Python tracker <https://bugs.python.org/issue37221> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37250] C files generated by Cython set tp_print to 0: PyTypeObject.tp_print removed
Jeroen Demeyer added the comment: Can we then bring back the discussion to the core of this issue: should we restore tp_print or not in PyTypeObject? Note that the PR for the other similar issue #37221 has been accepted for merging. -- ___ Python tracker <https://bugs.python.org/issue37250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37250] C files generated by Cython set tp_print to 0: PyTypeObject.tp_print removed
Jeroen Demeyer added the comment: If we're in doubt, we should just apply PR 14193. It's essentially a one-line patch that fixes actual problems experienced by users and which doesn't break anything. Why should we *not* apply it? I know that we're not obliged to fix anything, but that is besides the point given that a fix exists. -- ___ Python tracker <https://bugs.python.org/issue37250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37250] C files generated by Cython set tp_print to 0: PyTypeObject.tp_print removed
Jeroen Demeyer added the comment: > Perhaps it would be helpful for someone to recap the current options on the > table for moving forward and the most significant risk to Cython, Projects > using Cython, or CPython by selecting each option. There are three options: (1) Status-quo (keep everything as is in 3.8b1): this breaks any Cython project which has not been recythonized with the latest Cython. For example, it is (together with bpo-37221 which is planned to be fixed) the reason that "pip install numpy" doesn't work with 3.8b1. Typically, projects run Cython at packaging time, so this needs a new source release of every single Cython-using package. (2) Apply PR 14193: the only disadvantage that I can think of is that types would get 8 bytes larger. We should stop discussing and just do this. (3) Put back tp_print the way it was in 3.7: same as (2), except that it goes against PEP 590 as putting tp_vectorcall_offset in place of tp_print was a design decision made in that PEP. It would break ABI (any static type compiled with 3.7 would break on 3.8) and it prevents Cython from backporting vectorcall to 3.7. It's also a larger change compared to 3.8b1, so it's more work and more risky. In my personal opinion, the worst of the three options. Then there is the further question whether we should apply this only on 3.8 or possibly also later versions. But here the consensus seems to be 3.8 only. -- ___ Python tracker <https://bugs.python.org/issue37250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37250] C files generated by Cython set tp_print to 0: PyTypeObject.tp_print removed
Jeroen Demeyer added the comment: > Is four months really an unreasonable timeline? I thought most of these > packages released more frequently than CPython. I'm mostly worried about dependency chains. Right now, any project which depends on numpy cannot even test on 3.8b1 because numpy doesn't build. -- ___ Python tracker <https://bugs.python.org/issue37250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37358] Use vectorcall for functools.partial
New submission from Jeroen Demeyer : functools.partial already has some optimizations to use vectorcall (formerly known as fastcall) for its onward calls, so it makes a lot of sense to also use vectorcall when being called. -- components: Library (Lib) messages: 346193 nosy: Mark.Shannon, jdemeyer, petr.viktorin, vstinner priority: normal severity: normal status: open title: Use vectorcall for functools.partial type: performance versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue37358> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37358] Use vectorcall for functools.partial
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +14106 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14284 ___ Python tracker <https://bugs.python.org/issue37358> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37250] C files generated by Cython set tp_print to 0: PyTypeObject.tp_print removed
Jeroen Demeyer added the comment: > based on precedents that do not apply to this situation I'm curious what you mean here... -- ___ Python tracker <https://bugs.python.org/issue37250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37097] python_is_optimized() false negatives
Jeroen Demeyer added the comment: Never mind, I probably tested wrong here. -- resolution: -> works for me stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue37097> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37382] Improve conditional check for test_gdb
New submission from Jeroen Demeyer : Many tests in test_gdb are not run if python_is_optimized() is true. However, it's not entirely clear why we have this condition. For example, on my system, with the default CPython configuration, Python *is* optimized but still all gdb tests pass if I artificially enable them. Maybe we need debug symbols, but the existence of debug symbols and optimization are orthogonal. -- components: Tests messages: 346358 nosy: benjamin.peterson, jdemeyer priority: normal severity: normal status: open title: Improve conditional check for test_gdb type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue37382> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20177] Derby #8: Convert 28 sites to Argument Clinic across 2 files
Change by Jeroen Demeyer : -- pull_requests: +14150 pull_request: https://github.com/python/cpython/pull/14330 ___ Python tracker <https://bugs.python.org/issue20177> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37382] Improve conditional check for test_gdb
Jeroen Demeyer added the comment: The tests FAIL when CPython is compiled with "-O0 -g0" (without optimizations, without debug info) but tests PASS when compiled with "-O3 -g", showing that the check for "-g" is the right one. -- ___ Python tracker <https://bugs.python.org/issue37382> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37382] Improve conditional check for test_gdb
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +14151 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14331 ___ Python tracker <https://bugs.python.org/issue37382> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37382] Improve conditional check for test_gdb
Jeroen Demeyer added the comment: > Depending on the compiler optimization level, gdb may or may not br able to > read variables and function arguments. I haven't seen that problem. As I said, all GDB tests pass when compiled with "-O3 -g". > IHMO it is fine to skip test_gdb if Python "is optimized". The fact that these GDB tests are not run in any CI build is bad. For example, we had a buildbot failure after merging PEP 590 because of this. We should try to catch test breakage as early as possible, the buildbot should be the last resort. -- ___ Python tracker <https://bugs.python.org/issue37382> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37382] Improve conditional check for test_gdb
Jeroen Demeyer added the comment: > If you modify code which can impact test_gdb, you can run test_gdb locally I do run test_gdb locally but it's not very useful since most tests are skipped by default because python_is_optimized() is True. That's the whole point of this issue: tests are skipped without a good reason. -- ___ Python tracker <https://bugs.python.org/issue37382> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37382] Improve conditional check for test_gdb
Jeroen Demeyer added the comment: > The worst debugging experience is provided by PGO build. That's true but unrelated to this issue. We already skip test_gdb completely when PGO is enabled. -- ___ Python tracker <https://bugs.python.org/issue37382> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37382] Improve conditional check for test_gdb
Change by Jeroen Demeyer : -- pull_requests: +14209 pull_request: https://github.com/python/cpython/pull/14395 ___ Python tracker <https://bugs.python.org/issue37382> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37382] Improve conditional check for test_gdb
Jeroen Demeyer added the comment:
I meant this part in test_gdb.py:
if ((sysconfig.get_config_var('PGO_PROF_USE_FLAG') or 'xxx') in
(sysconfig.get_config_var('PY_CORE_CFLAGS') or '')):
raise unittest.SkipTest("test_gdb is not reliable on PGO builds")
--
___
Python tracker
<https://bugs.python.org/issue37382>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37382] Improve conditional check for test_gdb
Jeroen Demeyer added the comment: These python_is_optimized() tests were added in #8605 and #13628. Those issues talk about tests failing when CPython is compiled with -O2 or -O3. But, as I said here, I see no problems today with gcc -O3. So I'm guessing that either gcc or gdb improved such that these tests pass with more recent versions. -- ___ Python tracker <https://bugs.python.org/issue37382> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37382] Improve conditional check for test_gdb
Jeroen Demeyer added the comment: > Maybe open an issue to attempt to install gdb on Travis CI? I created PR 14395 for this. -- ___ Python tracker <https://bugs.python.org/issue37382> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33926] test_gdb is skipped in builds since gdb is not installed as part of build script
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +14233 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14395 ___ Python tracker <https://bugs.python.org/issue33926> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32926] Add public TestCase method/property to get result of current test
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +14234 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14395 ___ Python tracker <https://bugs.python.org/issue32926> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32926] Add public TestCase method/property to get result of current test
Change by Jeroen Demeyer : -- pull_requests: +14235 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14395 ___ Python tracker <https://bugs.python.org/issue32926> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32926] Add public TestCase method/property to get result of current test
Change by Jeroen Demeyer : -- pull_requests: -14235 ___ Python tracker <https://bugs.python.org/issue32926> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33926] test_gdb is skipped in builds since gdb is not installed as part of build script
Jeroen Demeyer added the comment: Feel free to close... -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue33926> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37406] Disable runtime checks in release mode
Jeroen Demeyer added the comment: > Python's exception mechanism is a much better way to signal and handle such > errors at the application level. I disagree. There is a difference between exceptions which are possible in normal usage of the code and real bugs, which shouldn't ever happen. A NULL argument to a C API function is not an ordinary exception, it's a real bug. Even if we raise a Python exception for that, it should never be handled in a try/exception block like an ordinary exception. > Using assert() in C is a pretty bad alternative, since this crashes the whole > process. I *prefer* debugging an assert() failure (which is pretty easy with a decent debugger) rather than debugging a Python exception raised from C (which typically does NOT give a useful traceback). -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue37406> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36926] Implement methoddescr_call without _PyMethodDef_RawFastCallDict
Jeroen Demeyer added the comment: Superseded by PR 13781 -- resolution: -> duplicate stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue36926> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37231] Optimize calling special methods
Change by Jeroen Demeyer : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue37231> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36924] Simplify implementation of classmethod_descriptor.__call__
Change by Jeroen Demeyer : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue36924> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36904] Implement _PyStack_UnpackDict() with a single allocation
Change by Jeroen Demeyer : -- pull_requests: +14333 pull_request: https://github.com/python/cpython/pull/14517 ___ Python tracker <https://bugs.python.org/issue36904> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37382] Improve conditional check for test_gdb
Jeroen Demeyer added the comment: > if a change like that is pushed, all the fleet has to be monitored for > potential failures, as there are many older OSes supported there. If this breaks some buildbots, then we can find out more precisely under which conditions they fail. For example, if they fail when GDB is older than a certain version, we can adjust the tests to check for that version. -- ___ Python tracker <https://bugs.python.org/issue37382> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37233] Use _PY_FASTCALL_SMALL_STACK for method_vectorcall
Change by Jeroen Demeyer : -- pull_requests: +14367 pull_request: https://github.com/python/cpython/pull/14550 ___ Python tracker <https://bugs.python.org/issue37233> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37138] PEP 590 method_vectorcall calls memcpy with NULL src
Change by Jeroen Demeyer : -- pull_requests: +14368 pull_request: https://github.com/python/cpython/pull/14550 ___ Python tracker <https://bugs.python.org/issue37138> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37483] Add PyObject_CallOneArg()
New submission from Jeroen Demeyer : As discussed in https://mail.python.org/archives/list/capi-...@python.org/thread/X6HJOEX6RRFLNKAQSQR6HLD7K4QZ4OTZ/ it would be convenient to have a function PyObject_CallOneArg() for making calls with exactly 1 positional argument and no keyword arguments. Such calls are very common. This would be analogous to PyObject_CallNoArgs(). -- components: Interpreter Core messages: 347138 nosy: jdemeyer, vstinner priority: normal severity: normal status: open title: Add PyObject_CallOneArg() type: performance versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue37483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37484] Use PY_VECTORCALL_ARGUMENTS_OFFSET for __exit__
New submission from Jeroen Demeyer : 35% of all cases where methods are called without PY_VECTORCALL_ARGUMENT_OFFSET and taking at least 1 argument (positional or keyword) are calls to __exit__ So we should really optimize __exit__ -- components: Interpreter Core messages: 347139 nosy: inada.naoki, jdemeyer priority: normal severity: normal status: open title: Use PY_VECTORCALL_ARGUMENTS_OFFSET for __exit__ type: performance versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue37484> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37484] Use PY_VECTORCALL_ARGUMENTS_OFFSET for __exit__
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +14373 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14557 ___ Python tracker <https://bugs.python.org/issue37484> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36904] Implement _PyStack_UnpackDict() with a single allocation
Change by Jeroen Demeyer : -- resolution: -> wont fix stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue36904> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37483] Add PyObject_CallOneArg()
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +14374 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14558 ___ Python tracker <https://bugs.python.org/issue37483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37483] Add PyObject_CallOneArg()
Jeroen Demeyer added the comment: Variadic macros are not part of C89, so that would require changing PEP 7. -- ___ Python tracker <https://bugs.python.org/issue37483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37483] Add PyObject_CallOneArg()
Jeroen Demeyer added the comment: > Cons: readability... It's a single relatively short macro. I'm not worried about that. I'm more about compiler support for such macros. I'll make a PR with this idea and see what CI says. -- ___ Python tracker <https://bugs.python.org/issue37483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37483] Add PyObject_CallOneArg()
Jeroen Demeyer added the comment: > _PyObject_CALL_WITH_ARGS(func, PyDict_GetItem(d, key)); // PyDict_GetItem(d, > key) is called twice. That's pretty bad and in my opinion a good reason to reject this idea. > If two or more arguments are not common, I prefer _PyObject_CallOneArg to > macro. I posted some counts at https://mail.python.org/archives/list/capi-...@python.org/message/3I76R27YMFSKB5JQIM3E4NA3BECVTZHP/ -- ___ Python tracker <https://bugs.python.org/issue37483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37483] Add PyObject_CallOneArg()
Jeroen Demeyer added the comment: > _PyObject_CALL_WITH_ARGS(func, PyDict_GetItem(d, key)); // PyDict_GetItem(d, > key) is called twice. Actually, it's not a problem: sizeof() is special, it only looks at the type of its argument, it doesn't execute the code. -- ___ Python tracker <https://bugs.python.org/issue37483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37483] Add PyObject_CallOneArg()
Jeroen Demeyer added the comment: > PEP 7 uses C99 since Python 3.6: > https://www.python.org/dev/peps/pep-0007/#c-dialect That's not what the PEP says: "Python versions greater than or equal to 3.6 use C89 with several select C99 features" "several select C99 features" is not the same of using C99. Plus, I'm also worried about C++. We also support compiling C++ extensions with the same header files, so it must be C++ compatible also. -- ___ Python tracker <https://bugs.python.org/issue37483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37483] Add PyObject_CallOneArg()
Jeroen Demeyer added the comment: Exactly. I see no reason to prefer PyObject_CallFunctionObjArgs(func, arg, NULL) over _PyObject_CallOneArg(func, arg) -- ___ Python tracker <https://bugs.python.org/issue37483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37483] Add PyObject_CallOneArg()
Jeroen Demeyer added the comment: > It adds yet another special case underscore function that one cannot use in > external projects. So I would not say that is simpler. If you're worried about the underscore, I will make a separate PR to add a non-underscored version, similar to PyObject_CallNoArgs() -- ___ Python tracker <https://bugs.python.org/issue37483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37483] Add PyObject_CallOneArg()
Jeroen Demeyer added the comment: > Is there any benchmark showing if it's faster Here is one example: class D(dict): def __missing__(self, key): return None d = D() and now benchmark d[0] **before**: Mean +- std dev: 173 ns +- 1 ns **after**: Mean +- std dev: 162 ns +- 1 ns To be precise, I ran: ./python -m perf timeit --duplicate 200 -s 'class D(dict):' -s ' def __missing__(self, key):' -s ' return None' -s 'd = D()' 'd[0]' -- ___ Python tracker <https://bugs.python.org/issue37483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37483] Add PyObject_CallOneArg()
Jeroen Demeyer added the comment: Stefan: I used an underscore by analogy with PyObject_CallNoArgs()/_PyObject_CallNoArg(), where the first is in the limited API and the second is an inline function in the cpython API. But maybe we could revisit that decision. -- ___ Python tracker <https://bugs.python.org/issue37483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37483] Add PyObject_CallOneArg()
Jeroen Demeyer added the comment: Victor, what's your opinion on adding PyObject_CallOneArg() to the limited API? -- ___ Python tracker <https://bugs.python.org/issue37483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37493] Use _PyObject_CallNoArg() in a few more places
New submission from Jeroen Demeyer : Try to use _PyObject_CallNoArg in all places where a function is called without arguments. -- components: Interpreter Core messages: 347230 nosy: jdemeyer priority: normal severity: normal status: open title: Use _PyObject_CallNoArg() in a few more places versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue37493> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37493] Use _PyObject_CallNoArg() in a few more places
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +14393 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14575 ___ Python tracker <https://bugs.python.org/issue37493> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37483] Add PyObject_CallOneArg()
Jeroen Demeyer added the comment:
Test of stack usage:
from _testcapi import stack_pointer
class D(dict):
def __missing__(self, key):
sp = stack_pointer()
print(f"stack usage = {TOP - sp}")
return None
d = D()
TOP = stack_pointer()
d[0]
**before**: stack usage = 1296
**after**: stack usage = 976
--
___
Python tracker
<https://bugs.python.org/issue37483>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37483] Add PyObject_CallOneArg()
Change by Jeroen Demeyer : -- pull_requests: +14394 pull_request: https://github.com/python/cpython/pull/14575 ___ Python tracker <https://bugs.python.org/issue37483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29312] Use FASTCALL in dict.update()
Jeroen Demeyer added the comment: For the benefit of PR 37207, I would like to re-open this discussion. It may have been rejected for the wrong reasons. Victor's patch was quite inefficient, but that's to be expected: msg285744 mentions a two-step process, but during the discussion the second steps seems to have been forgotten. -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue29312> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
