[issue37774] Micro-optimize vectorcall using PY_LIKELY
Jeroen Demeyer added the comment: > IHMO PGO compilation already defeats the purpose of these macros. That's certainly true. The question is whether we want to optimize also non-PGO builds. -- ___ Python tracker <https://bugs.python.org/issue37774> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37836] Support .as_integer_ratio() in fractions.Fraction
New submission from Jeroen Demeyer : Currently, the fractions.Fraction constructor accepts an .as_integer_ratio() method only for the specific types "float" and "Decimal". It would be good to support this for arbitrary classes. This is part of what was proposed in #37822, but without adding the math.operator() function. -- components: Library (Lib) messages: 349536 nosy: jdemeyer, mark.dickinson, rhettinger, serhiy.storchaka, stutzbach priority: normal severity: normal status: open title: Support .as_integer_ratio() in fractions.Fraction versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue37836> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37837] add internal _PyLong_FromUnsignedChar() function
Jeroen Demeyer added the comment: Maybe an even better idea would be to partially inline PyLong_FromLong(). If the check for small ints in PyLong_FromLong() would be inlined, then the compiler could optimize those checks. This would benefit all users of PyLong_FromLong() without code changes. -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue37837> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37774] Micro-optimize vectorcall using PY_LIKELY
Jeroen Demeyer added the comment: > If it's an optimization, can you show a benchmark to validate that it's > really faster as expected? Yes, I did test it. I didn't save the results, but I can redo them if you want. If you plan to reject the issue anyway, there is no point. > not building with PGO lead to random performances I would expect that Py_LIKELY/Py_UNLIKELY helps with this. If the compiler doesn't have probability information, it guesses. This can cause unrelated changes to change the heuristics used by the compiler, impacting the performance of some piece of code. With Py_LIKELY/Py_UNLIKELY, the code generated by the compiler should be more stable. -- ___ Python tracker <https://bugs.python.org/issue37774> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37774] Micro-optimize vectorcall using PY_LIKELY
Jeroen Demeyer added the comment: We're not talking about prefetching here. The Py_LIKELY/Py_UNLIKELY macros only affect which of the two code paths in a branch is the "default" one, i.e. the one not involving a jmp. -- ___ Python tracker <https://bugs.python.org/issue37774> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20861] datetime argument handling inconsistent; should accept logical integers, not coercible values
Jeroen Demeyer added the comment:
This is essentially a duplicate of #36048. The example is now deprecated:
>>> from decimal import Decimal
>>> from datetime import datetime
>>> datetime(Decimal("2000.5"), 1, 2)
:1: DeprecationWarning: an integer is required (got type
decimal.Decimal). Implicit conversion to integers using __int__ is deprecated,
and may be removed in a future version of Python.
datetime.datetime(2000, 1, 2, 0, 0)
So I think that this can be closed.
--
nosy: +jdemeyer
___
Python tracker
<https://bugs.python.org/issue20861>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37774] Micro-optimize vectorcall using PY_LIKELY
Jeroen Demeyer added the comment: I claim that adding Py_LIKELY/Py_UNLIKELY will reduce the performance randomness of non-PGO builds. So it would be strange to use that randomness as an argument *against* this patch. -- ___ Python tracker <https://bugs.python.org/issue37774> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37774] Micro-optimize vectorcall using PY_LIKELY
Jeroen Demeyer added the comment: > My question is if it is safe to let developers "abuse" it. If these macros > are misused, they can lead to a performance regression. I expect people using these macros and PR reviewers to use good judgement when to use these macros. There are many cases where the use of such macros should be uncontroversial, for example when checking for errors. > For example, if you mark the error path as unlikely: this path will become > slower. If the error path is taken "frequently" enough, the slowdown can > become significant overall. The speedup/slowdown that Py_LIKELY/Py_UNLIKELY gives is quite small, just a few clock cycles. This means that we shouldn't worry about performance regressions if the rest of the code takes much longer anyway. An example of this is raising exceptions, which typically involves PyErr_Format(). So I wouldn't worry too much about error paths getting slower. > About the macros, I would prefer to make it private to not promote it. I don't think it matters whether we call it Py_LIKELY or _Py_LIKELY. People that want to use it will use it anyway. And there is no issue with "provisional API" since this API is well-established in many existing projects. -- ___ Python tracker <https://bugs.python.org/issue37774> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc
Jeroen Demeyer added the comment: > Maybe repr(func) should be left unchanged, but str(func) can be enhanced? Yes, that is what I meant. -- ___ Python tracker <https://bugs.python.org/issue37645> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc
Change by Jeroen Demeyer : -- pull_requests: +15018 pull_request: https://github.com/python/cpython/pull/15295 ___ Python tracker <https://bugs.python.org/issue37645> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37540] vectorcall: keyword names must be strings
Change by Jeroen Demeyer : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue37540> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc
Jeroen Demeyer added the comment: > I'm wary of making error messages depend on the str representation of a > function; that would prevent us from changing it later. Why wouldn't we be able to change anything? Typically, the exact string of an error message is NOT part of the API (the exception *type* is, but we're not talking about that). > I'm wary of "%S" used in error messages. Those are for the programmer, not > the user I'm not following here. Given that Python is a programming language, the user *is* the programmer. Anyway, you don't have to be convinced. I'm trying to solve a problem here and I have two approaches (PR 14890 and PR 15295). I'm more inclined towards PR 15295, but if you like the idea of PR 14890 better, we can go with that instead. -- ___ Python tracker <https://bugs.python.org/issue37645> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc
Jeroen Demeyer added the comment: > I'm wary of "%S" used in error messages. Maybe you're misunderstanding something. The goal is not really to change error messages, only the way how they are produced. For example, we currently have >>> def f(): pass >>> f(**1) Traceback (most recent call last): File "", line 1, in TypeError: f() argument after ** must be a mapping, not int This is about how the "f()" in the error message is produced. Currently, this uses PyEval_GetFuncName() and PyEval_GetFuncDesc(). For the reasons explained in this issue, I want to replace that. I see two ways of doing this: 1. (PR 14890) Write a new function _PyObject_FunctionStr(func) which returns func.__qualname__ + "()" with a suitable fallback if there is no __qualname__ attribute. At some point, we could also introduce a %F format character for this. 2. (PR 15295) Use str(func) in the error message and change various __str__ methods (really tp_str functions) to give a more readable output. -- ___ Python tracker <https://bugs.python.org/issue37645> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37836] Support .as_integer_ratio() in fractions.Fraction
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +15045 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15327 ___ Python tracker <https://bugs.python.org/issue37836> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37836] Support .as_integer_ratio() in fractions.Fraction
Change by Jeroen Demeyer : -- pull_requests: +15046 pull_request: https://github.com/python/cpython/pull/15328 ___ Python tracker <https://bugs.python.org/issue37836> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37836] Support .as_integer_ratio() in fractions.Fraction
Jeroen Demeyer added the comment: > See issue37884 which uses a C accelerator. Note that that doesn't replace this issue, because I need to support as_integer_ratio both in the *numerator* and *denominator*. -- ___ Python tracker <https://bugs.python.org/issue37836> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37884] Optimize Fraction() and statistics.mean()
Jeroen Demeyer added the comment: > There is a 14% regression in creating a Fraction from an integer Isn't that the main use case? I suggest to keep the special case for 'int' as fast path to avoid this regression. -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue37884> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37836] Support .as_integer_ratio() in fractions.Fraction
Jeroen Demeyer added the comment: > I afraid this can slow down the Fraction constructor. No, it doesn't! It even speeds up the constructor in some cases: ./python -m perf timeit --duplicate 200 -s 'from fractions import Fraction; x = 1' 'Fraction(x)' BEFORE: Mean +- std dev: 826 ns +- 20 ns AFTER: Mean +- std dev: 814 ns +- 17 ns ./python -m perf timeit --duplicate 200 -s 'from fractions import Fraction; x = 1' 'Fraction(x, x)' BEFORE: Mean +- std dev: 1.44 us +- 0.03 us AFTER: Mean +- std dev: 1.46 us +- 0.02 us ./python -m perf timeit --duplicate 200 -s 'from fractions import Fraction; x = Fraction(1)' 'Fraction(x)' BEFORE: Mean +- std dev: 1.64 us +- 0.03 us AFTER: Mean +- std dev: 1.30 us +- 0.04 us ./python -m perf timeit --duplicate 200 -s 'from fractions import Fraction; x = Fraction(1)' 'Fraction(x, x)' BEFORE: Mean +- std dev: 3.03 us +- 0.05 us AFTER: Mean +- std dev: 2.34 us +- 0.06 us ./python -m perf timeit --duplicate 200 -s 'from fractions import Fraction; x = 1.0' 'Fraction(x)' BEFORE: Mean +- std dev: 1.82 us +- 0.02 us AFTER: Mean +- std dev: 1.29 us +- 0.04 us -- ___ Python tracker <https://bugs.python.org/issue37836> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37819] as_integer_ratio() missing from fractions.Fraction()
Jeroen Demeyer added the comment: > Sorry, but I do not understand why adding Fraction.as_integer_ratio() > prevents adding math.as_integer_ratio(). I also support a public function for that. It seems that we're planning this "as_integer_ratio" thing to become public API, so why not have a function as Serhiy proposes? I consider the situation with as_integer_ratio() very analogous to __index__ where we have operator.index(), so I would actually suggest operator.as_integer_ratio() but that's bikeshedding territory. -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue37819> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37884] Optimize Fraction() and statistics.mean()
Jeroen Demeyer added the comment: > ISTM that small and probably unimportant opimizations shouldn't spill-over > into API feature creep. The way I see it, the optimization is besides the point here. Regardless of performance, the added function is a useful feature to have to avoid forcing people to reinvent the wheel. For example, would you want the exact same code duplicated for fractions.Fraction() and for statictics.mean()? See also #37836 in case you didn't know about that issue. -- ___ Python tracker <https://bugs.python.org/issue37884> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37884] Optimize Fraction() and statistics.mean()
Jeroen Demeyer added the comment: > AFAICT, no end-user has ever requested this ever. What do you mean with "this"? (A) A public function like math.as_integer_ratio() (B) Using as_integer_ratio() in the fractions.Fraction() constructor (C) The optimization of the fractions.Fraction() constructor For SageMath, (B) would be very useful. See https://discuss.python.org/t/pep-3141-ratio-instead-of-numerator-denominator/2037/24?u=jdemeyer (replace __ratio__ by as_integer_ratio) -- ___ Python tracker <https://bugs.python.org/issue37884> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37884] Optimize Fraction() and statistics.mean()
Jeroen Demeyer added the comment: > our needs tend to be much different from end-users This issue is about fractions and statistics, which are closer to typical user libraries than CPython libraries. In fact, both could easily be packages on PyPI instead of part of the standard library. > no end-user has ever requested this ever. If math.as_integer_ratio() existed, probably SageMath would use it. On the other hand, the code for math.as_integer_ratio() is simple enough that SageMath could easily implement it if needed. -- ___ Python tracker <https://bugs.python.org/issue37884> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37913] Document that __length_hint__ may return NotImplemented
New submission from Jeroen Demeyer : The special method __length_hint__ can return NotImplemented. In this case, the result is as if the __length_hint__ method didn't exist at all. This behaviour is implemented and tested but not documented. -- assignee: docs@python components: Documentation messages: 350180 nosy: docs@python, jdemeyer priority: normal severity: normal status: open title: Document that __length_hint__ may return NotImplemented type: enhancement versions: Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue37913> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37913] Document that __length_hint__ may return NotImplemented
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +15093 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15383 ___ Python tracker <https://bugs.python.org/issue37913> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37884] Optimize Fraction() and statistics.mean()
Jeroen Demeyer added the comment: May I propose PR 15327 as alternative? It solves some of the same issues as the PR on this issue, in particular supporting arbitrary objects with as_integer_ratio(). It also improves performance somewhat for certain inputs, but that's more by accident. -- ___ Python tracker <https://bugs.python.org/issue37884> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37884] Optimize Fraction() and statistics.mean()
Jeroen Demeyer added the comment: > FWIW, the entire point of us having recently added as_integer_ratio() methods > to so many concrete classes is to avoid the need for helper functions in > favor of a simple try/except around a single call. But what about PEP 3141? The fractions.Fraction constructor accepts numbers.Rational instances, which do not necessarily have an as_integer_ratio() method. We can't just drop support for that (*). So in practice you do need to check both as_integer_ratio() and the PEP 3141 numerator/denominator properties. It seems useful to have a helper function for this. (*) Unless you want to deprecate PEP 3141. This may be less crazy than it sounds, especially given Guido van Rossum's reaction on https://discuss.python.org/t/pep-3141-ratio-instead-of-numerator-denominator/2037/25?u=jdemeyer -- ___ Python tracker <https://bugs.python.org/issue37884> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37934] Docs: Clarify NotImplemented use cases
Change by Jeroen Demeyer : -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue37934> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37884] Optimize Fraction() and statistics.mean()
Jeroen Demeyer added the comment: For the record: making a public math.as_integer_ratio() function was rejected at #37822. -- ___ Python tracker <https://bugs.python.org/issue37884> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37934] Docs: Clarify NotImplemented use cases
Jeroen Demeyer added the comment: > As you say, we currently have only one usage of NotImplemented outside its > intended purpose. I know at least 3 in CPython, so it's not so rare to use NotImplemented for something else than binary operators: 1. __subclasshook__ 2. reducer_override (in pickling) 3. __length_hint__ > Of course, you might argue that _once Python has NotImplemented_, it can be > used elsewhere - but as I said, I don't think it should be encouraged. I'm not saying that it should be actively encouraged, but the documentation shouldn't be limited to just one use case. Given that NotImplemented exists, why shouldn't it be used in more cases to indicate that an operation is not implemented? -- ___ Python tracker <https://bugs.python.org/issue37934> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33418] Memory leaks in functions
Jeroen Demeyer added the comment: > It looks like a bug triggered on purpose. Absolutely. It's one of the many small issues that I found while working on PEP 590 and related things. -- ___ Python tracker <https://bugs.python.org/issue33418> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc
Jeroen Demeyer added the comment: > I left some comments on the PR. I don't see anything. Either I'm doing something wrong or GitHub is messed up. -- ___ Python tracker <https://bugs.python.org/issue37645> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44874] Deprecate Py_TRASHCAN_SAFE_BEGIN/END
Change by Jeroen Demeyer : -- nosy: +jdemeyer nosy_count: 4.0 -> 5.0 pull_requests: +26438 pull_request: https://github.com/python/cpython/pull/12607 ___ Python tracker <https://bugs.python.org/issue44874> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40608] PY3.8 GC segfault (Py_TRASHCAN_SAFE_BEGIN/END are not backwards compatible)
Jeroen Demeyer added the comment: I need to check, but I think this is a duplicate of bpo-35983, which still has PR 12607 open. -- ___ Python tracker <https://bugs.python.org/issue40608> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36907] Crash due to borrowed references in _PyStack_UnpackDict()
Change by Jeroen Demeyer : -- pull_requests: +13292 ___ Python tracker <https://bugs.python.org/issue36907> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36970] Rename _PyObject_FastCall functions
New submission from Jeroen Demeyer : As preparation for PEP 590, rename _PyObject_FastCallKeywords -> _PyObject_Vectorcall _PyObject_FastCallDict -> _PyObject_VectorcallDict -- components: Interpreter Core messages: 342892 nosy: Mark.Shannon, jdemeyer, petr.viktorin priority: normal severity: normal status: open title: Rename _PyObject_FastCall functions type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue36970> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36970] Rename _PyObject_FastCall functions
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +13347 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36970> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36970] Rename _PyObject_FastCall functions
Jeroen Demeyer added the comment: > Is it possible to rename Vectorcall, which looks good on its own but not > inside _PyObject_VectorcallDict()? I don't understand what you mean here? > _PyObject_FastCallDict is much easier to read. You think that "_PyObject_FastCallDict" is easier to read than "_PyObject_VectorcallDict"? I don't think that there is much difference. > Has the PEP been accepted? It still says "Draft". It's very close to being accepted, just some details to work out. -- ___ Python tracker <https://bugs.python.org/issue36970> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36970] Rename _PyObject_FastCall functions
Jeroen Demeyer added the comment: Now to justify the naming: the plan is to keep the name "fast call" for the PyMethodDef flag METH_FASTCALL but to use the name "vectorcall" in the more general API. I think that's a good idea regardless of PEP 590, as it makes it clear that _PyObject_Vectorcall is useful for more than just METH_FASTCALL functions. -- ___ Python tracker <https://bugs.python.org/issue36970> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36970] Rename _PyObject_FastCall functions
Jeroen Demeyer added the comment: > I would prefer to wait until the PEP is accepted before starting to push > changes ;-) I don't think it's wrong to propose and discuss changes already now. With the first beta of Python 3.8 getting close, it's better to be prepared already for the moment that PEP 590 is accepted. > Cython uses the FASTCALL calling convention. Please check with Stefan Behnel > to see fix it's ok to "remove" _PyObject_FastCallKeywords and > _PyObject_FastCallDict. It would be bad to suddently break all extensions > compiled with Cython. I checked, Cython does not use those *generic* _PyObject_FastCall functions. It does use more specialized functions like _PyFunction_FastCallDict and _PyMethodDef_RawFastCallKeywords. -- ___ Python tracker <https://bugs.python.org/issue36970> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36970] Rename _PyObject_FastCall functions
Jeroen Demeyer added the comment: > From the perspective of reading, it is one of the most obnoxious names I've > seen in the Python code base. PyObject_Vectorcall() is the name in PEP 590, so if you want to change it, better write to python-dev about it. -- ___ Python tracker <https://bugs.python.org/issue36970> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36971] Add subsections in C API "Common Object Structures" page
New submission from Jeroen Demeyer : The page https://docs.python.org/3/c-api/structures.html could be better structured by arranging the content in sub-sections. -- assignee: docs@python components: Documentation messages: 342911 nosy: docs@python, jdemeyer priority: normal severity: normal status: open title: Add subsections in C API "Common Object Structures" page versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue36971> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36971] Add subsections in C API "Common Object Structures" page
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +13354 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36971> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36974] Implement PEP 590
Change by Jeroen Demeyer : -- components: Interpreter Core nosy: Mark.Shannon, jdemeyer, petr.viktorin priority: normal severity: normal status: open title: Implement PEP 590 type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue36974> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36974] Implement PEP 590
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +13359 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36974> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36970] Rename _PyObject_FastCall functions
Jeroen Demeyer added the comment: The consensus on PEP 590 now seems to be to keep the name `_PyObject_FastCallDict` and rename only `_PyObject_FastCallKeywords` -> `_PyObject_Vectorcall`. For the record: I don't agree with this decision but I'll implement it. -- ___ Python tracker <https://bugs.python.org/issue36970> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36937] New _PyObject_MakeTpCall() function
Jeroen Demeyer added the comment: So what are you trying to say? That it *should* be a static function? It most likely won't be a static function after PEP 590 is fully implemented. -- ___ Python tracker <https://bugs.python.org/issue36937> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36937] New _PyObject_MakeTpCall() function
Jeroen Demeyer added the comment: In that case, there is no point a making a separate issue or PR. -- resolution: -> duplicate stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue36937> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36974] Implement PEP 590
Change by Jeroen Demeyer : -- pull_requests: +13367 ___ Python tracker <https://bugs.python.org/issue36974> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36974] Implement PEP 590
Change by Jeroen Demeyer : -- pull_requests: +13370 ___ Python tracker <https://bugs.python.org/issue36974> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36970] Rename _PyObject_FastCallKeywords
Jeroen Demeyer added the comment: What's your opinion on renaming also _PyCFunction_FastCallKeywords -> _PyCFunction_Vectorcall _PyFunction_FastCallKeywords -> _PyFunction_Vectorcall If you agree, I will add it to the PR. -- ___ Python tracker <https://bugs.python.org/issue36970> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36970] Rename _PyObject_FastCallKeywords
Change by Jeroen Demeyer : -- title: Rename _PyObject_FastCall functions -> Rename _PyObject_FastCallKeywords ___ Python tracker <https://bugs.python.org/issue36970> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36994] Missing tests for CALL_FUNCTION_EX opcode profiling method_descriptor
New submission from Jeroen Demeyer : The branch for profiling a method_descriptor inside do_call_core is not tested by the test suite. -- components: Tests messages: 343044 nosy: jdemeyer priority: normal severity: normal status: open title: Missing tests for CALL_FUNCTION_EX opcode profiling method_descriptor versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue36994> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36994] Missing tests for CALL_FUNCTION_EX opcode profiling method_descriptor
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +13371 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36994> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36995] tp_print -> tp_vectorcall_offset
New submission from Jeroen Demeyer : If PEP 590 is accepted: in code comments, replace tp_print by tp_vectorcall_offset and (while we're at it) tp_reserved by tp_as_async. -- components: Interpreter Core messages: 343061 nosy: Mark.Shannon, jdemeyer, petr.viktorin priority: normal severity: normal status: open title: tp_print -> tp_vectorcall_offset versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue36995> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36970] Rename _PyObject_FastCallKeywords
Change by Jeroen Demeyer : -- resolution: -> duplicate stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue36970> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36995] tp_print -> tp_vectorcall_offset
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +13375 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36995> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36995] tp_print -> tp_vectorcall_offset
Jeroen Demeyer added the comment: I see what you mean now. One bpo issue with many pull requests. I was following the CPython policy that every pull request needed an issue, but it didn't occur to me to put multiple independent PRs on one issue. -- resolution: -> duplicate stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue36995> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36974] Implement PEP 590
Change by Jeroen Demeyer : -- pull_requests: +13397 ___ Python tracker <https://bugs.python.org/issue36974> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34125] Profiling depends on whether **kwargs is given
Jeroen Demeyer added the comment: This is missing a testcase: PR 13461 -- ___ Python tracker <https://bugs.python.org/issue34125> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36994] Missing tests for CALL_FUNCTION_EX opcode profiling method_descriptor
Change by Jeroen Demeyer : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue36994> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36907] Crash due to borrowed references in _PyStack_UnpackDict()
Jeroen Demeyer added the comment: > Jeroen, do you want to also do a backport for 3.7? Don't we have a bot for that? -- ___ Python tracker <https://bugs.python.org/issue36907> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36907] Crash due to borrowed references in _PyStack_UnpackDict()
Jeroen Demeyer added the comment: Using __int__ instead of __index__ works. PR coming right away. -- ___ Python tracker <https://bugs.python.org/issue36907> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36907] Crash due to borrowed references in _PyStack_UnpackDict()
Change by Jeroen Demeyer : -- pull_requests: +13408 ___ Python tracker <https://bugs.python.org/issue36907> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36974] Implement PEP 590
Change by Jeroen Demeyer : -- pull_requests: +13414 ___ Python tracker <https://bugs.python.org/issue36974> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36974] Implement PEP 590
Change by Jeroen Demeyer : -- pull_requests: +13547 pull_request: https://github.com/python/cpython/pull/13653 ___ Python tracker <https://bugs.python.org/issue36974> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22117] Rewrite pytime.h to work on nanoseconds
Jeroen Demeyer added the comment: Can somebody here explain the meaning of the comment in test_gdb.py # Tested function must not be defined with METH_NOARGS or METH_O, # otherwise call_function() doesn't call PyCFunction_Call() This test is breaking with PEP 590, see https://github.com/python/cpython/pull/13185 -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue22117> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22117] Rewrite pytime.h to work on nanoseconds
Jeroen Demeyer added the comment: Petr claims to have a fix, https://github.com/python/cpython/pull/13665 -- ___ Python tracker <https://bugs.python.org/issue22117> ___ ___ 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
New submission from Jeroen Demeyer :
The function python_is_optimized() in Lib/test/support.py:
def python_is_optimized():
"""Find if Python was built with optimizations."""
cflags = sysconfig.get_config_var('PY_CFLAGS') or ''
final_opt = ""
for opt in cflags.split():
if opt.startswith('-O'):
final_opt = opt
return final_opt not in ('', '-O0', '-Og')
However, it seems that the *default* (when no special CFLAGS are configured) is
-O3. My Python build is done with this default -O3 but python_is_optimized()
returns False. This is the reason why I didn't catch the buildbot failure at
https://github.com/python/cpython/pull/13185#issuecomment-497062965
(this test is only run when python_is_optimized() is True)
--
components: Tests
messages: 343952
nosy: benjamin.peterson, jdemeyer, petr.viktorin, pitrou
priority: normal
severity: normal
status: open
title: python_is_optimized() false negatives
type: behavior
versions: Python 3.8, Python 3.9
___
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
[issue26836] Add memfd_create to os module
Jeroen Demeyer added the comment: Testsuite breakage: https://bugs.python.org/issue37098 -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue26836> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37098] test_memfd_create() test failure
New submission from Jeroen Demeyer :
On an older Linux system:
==
ERROR: test_memfd_create (test.test_os.MemfdCreateTests)
--
Traceback (most recent call last):
File "/usr/local/src/sage-config/local/src/cpython/Lib/test/test_os.py", line
3128, in test_memfd_create
fd = os.memfd_create("Hi", os.MFD_CLOEXEC)
OSError: [Errno 38] Function not implemented
--
components: Tests
messages: 343953
nosy: ZackerySpytz, christian.heimes, jdemeyer
priority: normal
severity: normal
status: open
title: test_memfd_create() test failure
type: behavior
versions: Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue37098>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36974] Implement PEP 590
Change by Jeroen Demeyer : -- pull_requests: +13569 pull_request: https://github.com/python/cpython/pull/13682 ___ Python tracker <https://bugs.python.org/issue36974> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36974] Implement PEP 590
Change by Jeroen Demeyer : -- pull_requests: +13666 pull_request: https://github.com/python/cpython/pull/13781 ___ Python tracker <https://bugs.python.org/issue36974> ___ ___ 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
New submission from Jeroen Demeyer : Now that PEP 590 has been implemented, a lot of old code can be cleaned up. In particular: - get rid of _PyMethodDef_RawFastCallXXX() functions and replace them by vectorcall functions for each calling convention - get rid of FastCallDict() implementations for specific types, but keep the generic _PyObject_FastCallDict() - get rid of some specific tp_call implementations: try to use tp_call=PyVectorcall_Call in more places -- components: Interpreter Core messages: 344577 nosy: Mark.Shannon, jdemeyer, petr.viktorin priority: normal severity: normal status: open title: Calling code cleanup after PEP 590 type: enhancement versions: Python 3.9 ___ 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
[issue36924] Simplify implementation of classmethod_descriptor.__call__
Jeroen Demeyer added the comment: I opened a more general issue #37151 -- ___ 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
[issue37151] Calling code cleanup after PEP 590
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +13694 stage: -> patch review pull_request: https://github.com/python/cpython/pull/13340 ___ 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
[issue22117] Rewrite pytime.h to work on nanoseconds
Jeroen Demeyer added the comment: > Commenting closed issues is not the most efficient way to get an answer ;-) Serious question: why is that? I got an email from bugs.python.org with your comment, so why should commenting on closed issues be any worse than commenting on open issues? Especially if the people on the issue are still active core developers. -- ___ Python tracker <https://bugs.python.org/issue22117> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22117] Rewrite pytime.h to work on nanoseconds
Jeroen Demeyer added the comment: Right, but my question was very specifically about a test added for this issue. So asking it here first made sense to me. If nobody would reply, I could still ask somewhere else. In the end, Petr solved the problem anyway, so the question is irrelevant now. -- ___ Python tracker <https://bugs.python.org/issue22117> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36974] Implement PEP 590
Change by Jeroen Demeyer : -- pull_requests: +13721 pull_request: https://github.com/python/cpython/pull/13844 ___ Python tracker <https://bugs.python.org/issue36974> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36974] Implement PEP 590
Change by Jeroen Demeyer : -- pull_requests: +13733 pull_request: https://github.com/python/cpython/pull/13858 ___ Python tracker <https://bugs.python.org/issue36974> ___ ___ 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: +13740 pull_request: https://github.com/python/cpython/pull/13864 ___ 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
[issue36922] Implement Py_TPFLAGS_METHOD_DESCRIPTOR
Change by Jeroen Demeyer : -- pull_requests: +13741 pull_request: https://github.com/python/cpython/pull/13865 ___ Python tracker <https://bugs.python.org/issue36922> ___ ___ 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
Jeroen Demeyer added the comment: That's entirely my fault. I was not aware of the fact that calling memcpy() with src=NULL and length 0 was undefined behaviour. I disagree that it should be undefined, but there is not much point in arguing against the C standard. -- nosy: +jdemeyer ___ 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
[issue37138] PEP 590 method_vectorcall calls memcpy with NULL src
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +13743 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/13867 ___ 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
[issue37176] super() docs don't say what super() does
New submission from Jeroen Demeyer : The documentation for super() at https://docs.python.org/3.8/library/functions.html#super does not actually say what super() does. It only says "Return a proxy object that delegates method calls to a parent or sibling class of type" and then gives a bunch of use cases and examples. If there is one place where we should define exactly what super() does (as opposed to give guidance on how to use it), the stdlib reference should be it. -- assignee: docs@python components: Documentation messages: 344827 nosy: docs@python, jdemeyer priority: normal severity: normal status: open title: super() docs don't say what super() does type: enhancement versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue37176> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18355] Merge super() guide into documentation
Jeroen Demeyer added the comment: I opened another doc issue about super(): #37176 -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue18355> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37176] super() docs don't say what super() does
Jeroen Demeyer added the comment: > What more do you want? Mainly: it says "a parent or sibling class of *type*" but it doesn't explain which class it actually uses. And the sentence "The __mro__ attribute of the type lists the method resolution search order used by both getattr() and super()" is even wrong or at least confusing: what matters is not the MRO of the type (the first argument to super()) but the MRO of the object (the second argument to super()). The zero-argument form super() is not explained at all. > Perhaps there ought to be a "gentle guide to super" somewhere, and the docs > could link to that? There are plenty of guides like that and in fact that docs already link to https://rhettinger.wordpress.com/2011/05/26/super-considered-super/ -- ___ Python tracker <https://bugs.python.org/issue37176> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37176] super() docs don't say what super() does
Jeroen Demeyer added the comment: > Only one of the two arguments is called "type". The other is called "object-or-type". I'm having problems with the first word of "a parent or sibling class of type". The most important part of super() is to *which* class that attribute lookups are delegated to and this is not explained. > The __mro__ attribute is on the type, not the instance: Sorry for that. I meant to say: And the sentence "The __mro__ attribute of the type lists the method resolution search order used by both getattr() and super()" is even wrong or at least confusing: what matters is not the MRO of the type (the first argument to super()) but the MRO of ***the type of*** the object (the second argument to super()). > Yes it is. Look at the example given: An example is not an explanation. But it's true, this is the least of my problems with this doc. -- ___ Python tracker <https://bugs.python.org/issue37176> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37176] super() docs don't say what super() does
Jeroen Demeyer added the comment: > The sentence doesn't talk about the MRO of *type* (the first argument), it talks about the __mro__ attribute. If you have to explain in a bpo issue how the doc should be read, that proves exactly my point that it's confusing. The fact that it's technically correct if you read it the right way is irrelevant. -- ___ Python tracker <https://bugs.python.org/issue37176> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37194] Move new vector private declarations to the internal C API
Jeroen Demeyer added the comment: > I propose to move the new *private* declarations to the internal C API. Some of those functions (in particular _PyObject_Vectorcall) are expected to become public in 3.9. They are only private for now since the API is provisional. -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue37194> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37191] Python.h contains intermingled declarations
Jeroen Demeyer added the comment: Should we revert these inline functions back to macros? -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue37191> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37191] Python.h contains intermingled declarations
Jeroen Demeyer added the comment: > It's well within our rights to ignore this: since 3.6 we require intermingled > declarations. It's not clear from PEP 7 if we require intermingled declarations only when compiling CPython itself, or also for external packages that include CPython headers. It would be prudent to stay C89-compatible for non-internal header files. -- ___ Python tracker <https://bugs.python.org/issue37191> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37176] super() docs don't say what super() does
Jeroen Demeyer added the comment: > What matters is the __mro__ attribute of the first argument. It matters because that is how the MRO actually is searched. I'm sorry to say that you're wrong here. super() looks at the MRO of the type of the object (the second argument) (*). It has to do that in order to support diamonds. Consider a diamond like D / \ B C \ / A (with A as common base class). Now super(B, D()).attr will look in the MRO of D (which is D, B, C, A) and therefore delegate to C.attr. In this case, C does not even appear in the MRO of B. (*) To be pedantic: in the special case that the second argument is a type itself, it looks at the MRO of the second argument. -- ___ Python tracker <https://bugs.python.org/issue37176> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37176] super() docs don't say what super() does
Jeroen Demeyer added the comment: And this last comment is precisely the kind of information which should be explained in the super() docs. -- ___ Python tracker <https://bugs.python.org/issue37176> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37176] super() docs don't say what super() does
Jeroen Demeyer added the comment: > Some of the problems brought up here (which sibling or subclass, and which > parameter’s MRO) also came up a few years ago in Issue 23674. Indeed. I would actually say that these two issues are duplicates of each other. -- ___ Python tracker <https://bugs.python.org/issue37176> ___ ___ 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: > Take into account that doing such rename will break again the projects that > have adapted already (primarily only Cython). +1. You already broke backwards compatibility once in beta1, no need to do it again in beta2. -- nosy: +jdemeyer ___ 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
[issue37151] Calling code cleanup after PEP 590
Change by Jeroen Demeyer : -- pull_requests: +13839 pull_request: https://github.com/python/cpython/pull/13972 ___ 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
[issue37231] Optimize calling special methods
New submission from Jeroen Demeyer : Change call_method() and related functions in Objects/typeobject.c to allow profiting from the PY_VECTORCALL_ARGUMENTS_OFFSET optimization: instead of passing "self" as separate argument, put it inside the args vector. -- components: Interpreter Core messages: 345231 nosy: jdemeyer priority: normal severity: normal status: open title: Optimize calling special methods type: performance versions: Python 3.9 ___ 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
[issue37231] Optimize calling special methods
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +13840 stage: -> patch review pull_request: https://github.com/python/cpython/pull/13973 ___ 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
[issue37233] Use _PY_FASTCALL_SMALL_STACK for method_vectorcall
New submission from Jeroen Demeyer : The PEP 590 implementation for type "method" caused a minor regression: instead of using _PyObject_Call_Prepend(), method_vectorcall manually allocates and fills a newly allocated vector. This does NOT use the _PY_FASTCALL_SMALL_STACK optimization, but it should. -- components: Interpreter Core messages: 345234 nosy: jdemeyer priority: normal severity: normal status: open title: Use _PY_FASTCALL_SMALL_STACK for method_vectorcall type: performance versions: Python 3.9 ___ 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
[issue37233] Use _PY_FASTCALL_SMALL_STACK for method_vectorcall
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +13841 stage: -> patch review pull_request: https://github.com/python/cpython/pull/13974 ___ 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
