[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
[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
[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
[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
[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
[issue29312] Use FASTCALL in dict.update()
Jeroen Demeyer added the comment: > d2 must be converted to 2 lists (kwnames and args) and then a new dict should > be created. The last part is not necessarily true. You could do the update directly, without having that intermediate dict. -- ___ 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
[issue37588] Py_DEPRECATED and unavoidable warnings
Jeroen Demeyer added the comment: See also https://github.com/python/cpython/pull/14193#pullrequestreview-251630953 -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue37588> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37562] PEP 590 implementation may have introduced a performance regression
Jeroen Demeyer added the comment: I did some benchmarks WITHOUT PGO (simply because it's much faster to compile and therefore easier to test things out). The command I used for testing is ./python -m perf timeit --duplicate 200 -s 'f = len; x = ()' 'f(x)' * d30da5dd9a8a965cf24a22bbaff8a5b1341c2944 (before PEP 590) Mean +- std dev: 25.1 ns +- 0.2 ns * aacc77fbd77640a8f03638216fa09372cc21673d (first commit of PEP 590) Mean +- std dev: 29.3 ns +- 0.9 ns * b8e198a5d09ca876b87baaf6efd2b2e7c9e3a0b3 (3.8 branch) Mean +- std dev: 29.5 ns +- 0.3 ns * cd6e83b4810549c308ab2d7315dbab526e35ccf6 (master) Mean +- std dev: 25.1 ns +- 0.2 ns So there does seem to be a regression with 3.8 but not with 3.9. I don't know what to do with this... can we backport more of the PEP 590 commits to 3.8? Or will the release manager complain? -- ___ Python tracker <https://bugs.python.org/issue37562> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1583] Patch for signal.set_wakeup_fd
Jeroen Demeyer added the comment: Why is this using type "sig_atomic_t" for a file descriptor instead of "int" (which is the type of file descriptors)? See https://github.com/python/cpython/pull/12670 -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue1583> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35381] posixmodule: convert statically allocated types (DirEntryType & ScandirIteratorType) to heap-allocated types
Jeroen Demeyer added the comment: Just curious... how is PEP 384 relevant to modules insides CPython itself? I thought that this only mattered for external packages. Do you expect people to use a 3.7-compiled posixmodule.c on Python 3.8? -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue35381> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36710] Pass _PyRuntimeState as an argument rather than using the _PyRuntime global variable
Jeroen Demeyer added the comment: I don't really understand the rationale for these changes. What's wrong with the global variable _PyRuntime? What's the long-term goal for _PyRuntime? If you can't get rid of all occurrences of _PyRuntime, how does it help to get rid of *some* occurences? -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue36710> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37562] PEP 590 implementation may have introduced a performance regression
Jeroen Demeyer added the comment: PR 14782 (backport of PR 13781) fixes the regression for me. -- ___ Python tracker <https://bugs.python.org/issue37562> ___ ___ 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: +14578 pull_request: https://github.com/python/cpython/pull/14782 ___ 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
[issue37562] PEP 590 implementation may have introduced a performance regression
Change by Jeroen Demeyer : -- pull_requests: +14579 pull_request: https://github.com/python/cpython/pull/14782 ___ Python tracker <https://bugs.python.org/issue37562> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37562] PEP 590 implementation may have introduced a performance regression
Change by Jeroen Demeyer : -- versions: -Python 3.9 ___ Python tracker <https://bugs.python.org/issue37562> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37499] test_gdb.test_pycfunction should use dedicated test functions
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +14589 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/14795 ___ Python tracker <https://bugs.python.org/issue37499> ___ ___ 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
[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
[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
[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
[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
[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
[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
[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
[issue35707] time.sleep() should support objects with __float__
Jeroen Demeyer added the comment: > If we want to support other numerical types with loss in double rounding, the > most reliable way is to represent them as fractions (x.as_integer_ratio() or > (x.numerator, x.denominator)) See https://discuss.python.org/t/pep-3141-ratio-instead-of-numerator-denominator/2037/24?u=jdemeyer for a proposal to define __ratio__ for this. -- ___ Python tracker <https://bugs.python.org/issue35707> ___ ___ 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: Another solution would be to change the __str__ of various function objects to a prettier output. For example, we currently have >>> def f(): pass >>> print(f) We could change this to >>> def f(): pass >>> print(f) f() and then use "%S" to display the functions in error messages. But I have a feeling that this is a more controversial change than PR 14890. -- ___ 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
[issue37822] Add math.as_integer_ratio()
Jeroen Demeyer added the comment: Aren't you worried about using the non-special non-reserved attributes like "as_integer_ratio"? That's the reason why I proposed a dunder name "__ratio__" instead of "as_integer_ratio". In my opinion, it was a mistake in PEP 3141 to use non-reserved names like "numerator" and "denominator" because they might already be used by existing classes with a different meaning (this is precisely what happened with SageMath). It's an honest question. If you say, "we thought about it and think it's just fine to use as_integer_ratio()", just say so and that's fine for me. -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue37822> ___ ___ 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
[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
[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
[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
[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: > 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: > 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: > 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
[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
[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
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
[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
[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
[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
[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
[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
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
[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
[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
[issue28716] Fractions instantiation revisited
Jeroen Demeyer added the comment: See https://discuss.python.org/t/pep-3141-ratio-instead-of-numerator-denominator/2037/24?u=jdemeyer for a proposal to define a new dunder __ratio__ (instead of as_integer_ratio) for this. -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue28716> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31388] Provide a way to defer SIGINT handling in the current thread
Jeroen Demeyer added the comment: Another idea I had is to somehow deal with this in PyErr_WriteUnraisable: whenever PyErr_WriteUnraisable is called for a KeyboardInterrupt, defer that exception to a later time, for example when _PyEval_EvalFrameDefault() is called. -- ___ Python tracker <https://bugs.python.org/issue31388> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11165] Document PyEval_Call* functions
Jeroen Demeyer added the comment: These functions are now officially deprecated, see PR 14804. So I think that this issue can be closed. -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue11165> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33829] C API: provide new object protocol helper
Jeroen Demeyer added the comment: I agree with rejecting and closing this issue. -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue33829> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37562] PEP 590 implementation may have introduced a performance regression
Jeroen Demeyer added the comment: Please close -- ___ Python tracker <https://bugs.python.org/issue37562> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36974] Implement PEP 590
Jeroen Demeyer added the comment:
> Should we add a note like "if you get a 'SystemError: bad call flags' on
> import, check the descriptor flags of your functions" in What's New in Python
> 3.8?
A better solution would be to change the error message. We could change it to
something like SystemError("bad flags 0x2 for PyCOMPS_categories_match")
But maybe it's not worth it. Are there many projects that define
functions/methods but never call them?
--
___
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
[issue37774] Micro-optimize vectorcall using PY_LIKELY
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +14881 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15144 ___ 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
New submission from Jeroen Demeyer : Take the LIKELY/UNLIKELY macros out of Objects/obmalloc.c (renaming them of course). Use them in a few places to micro-optimize vectorcall. -- components: Interpreter Core messages: 349108 nosy: Mark.Shannon, inada.naoki, jdemeyer priority: normal severity: normal status: open title: Micro-optimize vectorcall using PY_LIKELY versions: Python 3.9 ___ 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
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +14673 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14890 ___ 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
New submission from Jeroen Demeyer : PyEval_GetFuncName is bad API because 1. It hardcodes a limited number of function classes (which doesn't even include all function classes in the core interpreter) instead of supporting duck-typing. 2. In case of a "function" object, it relies on a borrowed reference to the function. 3. It is returning a C string instead of a Python string, so we cannot return a new reference even if we wanted to. Since PyEval_GetFuncName and PyEval_GetFuncDesc are always used together, we might as well replace them by a single function with a proper API. -- components: Interpreter Core messages: 348255 nosy: jdemeyer, vstinner priority: normal severity: normal status: open title: Replace PyEval_GetFuncName/PyEval_GetFuncDesc versions: Python 3.9 ___ 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: 4. It uses the __name__ instead of the __qualname__ -- ___ 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
[issue37619] update_one_slot() should not ignore wrapper descriptors for wrong type
New submission from Jeroen Demeyer : >>> class S(str): ... __eq__ = int.__eq__ >>> S() == S() True The expectation is that this raises an exception because int.__eq__() is called on S instances. -- components: Interpreter Core messages: 348108 nosy: jdemeyer priority: normal severity: normal status: open title: update_one_slot() should not ignore wrapper descriptors for wrong type 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/issue37619> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37619] update_one_slot() should not ignore wrapper descriptors for wrong type
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +14627 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14836 ___ Python tracker <https://bugs.python.org/issue37619> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37588] Py_DEPRECATED and unavoidable warnings
Jeroen Demeyer added the comment: > We have some reserved/deprecated/unused fields. Setting 0 to them makes > forward incompatible code. Good point. tp_print is removed in 3.9 -- ___ Python tracker <https://bugs.python.org/issue37588> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37588] Py_DEPRECATED and unavoidable warnings
Jeroen Demeyer added the comment: I support the patch proposed in https://bugs.python.org/file48478/pyport.h.diff but it's not up to me to make that decision. -- ___ Python tracker <https://bugs.python.org/issue37588> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34396] Certain methods that heap allocated subtypes inherit suffer a 50-80% performance penalty
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +14652 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14863 ___ Python tracker <https://bugs.python.org/issue34396> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29548] Recommend PyObject_Call* APIs over PyEval_Call*() APIs
Change by Jeroen Demeyer : -- pull_requests: +14600 pull_request: https://github.com/python/cpython/pull/14804 ___ Python tracker <https://bugs.python.org/issue29548> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37588] Py_DEPRECATED and unavoidable warnings
Jeroen Demeyer added the comment: One possible solution would be to have a macro to suppress the tp_print field in the first place. Something like #ifndef PY_NO_TP_PRINT /* bpo-37250: kept for backwards compatibility in CPython 3.8 only */ Py_DEPRECATED(3.8) int (*tp_print)(PyObject *, FILE *, int); #endif -- ___ Python tracker <https://bugs.python.org/issue37588> ___ ___ 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
[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
[issue37540] vectorcall: keyword names must be strings
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +14487 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14682 ___ 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
[issue37483] Add PyObject_CallOneArg()
Change by Jeroen Demeyer : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ 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__
Change by Jeroen Demeyer : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ 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
[issue29548] Recommend PyObject_Call* APIs over PyEval_Call*() APIs
Change by Jeroen Demeyer : -- pull_requests: +14488 pull_request: https://github.com/python/cpython/pull/14683 ___ Python tracker <https://bugs.python.org/issue29548> ___ ___ 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
New submission from Jeroen Demeyer : Keyword names in calls are expected to be strings, however it's currently not clear who should enforce/check this. I suggest to fix this for vectorcall/METH_FASTCALL and specify that it's the caller's job to make sure that keyword names are strings (str subclasses are allowed). -- components: Interpreter Core messages: 347608 nosy: Mark.Shannon, jdemeyer, petr.viktorin, vstinner priority: normal severity: normal status: open title: vectorcall: keyword names must be strings type: enhancement versions: Python 3.9 ___ 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
[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
[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
