[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
[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
[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
[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
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: > 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
[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
[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: > 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
[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: > 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
[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
[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
[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
[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
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
[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
[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
[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
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
[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: > 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
[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
[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: 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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
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
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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
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
[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 will certainly have a look and try a few things, but it will probably be next week. -- ___ 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 introduced a performance regression
Jeroen Demeyer added the comment: Could you please specify: - which commits are you comparing exactly? From your explanation, I guess aacc77fbd and its parent, but that's not completely fair since PEP 590 consists of many commits (see #36974). A better comparison would be master against 3.8a4. - are you compiling with PGO (--enable-optimizations) or not? -- ___ 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
[issue29548] Recommend PyObject_Call* APIs over PyEval_Call*() APIs
Jeroen Demeyer added the comment: I understand the arguments for not removing these functions. However, I still think that we should deprecate them but without planning in advance when they should be removed. Victor said that we should document these functions as "please don't use them", and that is exactly what a deprecation message accomplishes. Most other projects that I know have only a minimum deprecation period (i.e. feature X can only be removed if it was deprecated for Y time). I don't understand why CPython insists that the minimum of 2 releases should also be a maximum (i.e. feature X MUST be removed after it was deprecated for Y time). I don't see the problem with long-term deprecations for stuff that we don't plan to remove soon. -- nosy: +jdemeyer ___ 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
[issue37547] Add _PyObject_CallMethodOneArg()
Change by Jeroen Demeyer : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue37547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37547] Add _PyObject_CallMethodOneArg()
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +14492 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14685 ___ Python tracker <https://bugs.python.org/issue37547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37547] Add _PyObject_CallMethodOneArg()
New submission from Jeroen Demeyer : We already have _PyObject_CallNoArg() _PyObject_CallOneArg() _PyObject_CallMethodNoArgs() so it makes sense to also add _PyObject_CallMethodOneArg() -- components: Interpreter Core messages: 347619 nosy: inada.naoki, jdemeyer, vstinner priority: normal severity: normal status: open title: Add _PyObject_CallMethodOneArg() type: performance versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue37547> ___ ___ 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: +14490 pull_request: https://github.com/python/cpython/pull/14684 ___ 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
[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
[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
[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
[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
[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
[issue29312] Use FASTCALL in dict.update()
Jeroen Demeyer added the comment: > but it will make d1.update(**d2) slower with a complexity of O(n): d2 must be > converted to 2 lists This part is still true and it causes a slow-down of about 23% for dict.update(**d), see benchmarks at https://github.com/python/cpython/pull/14589#issuecomment-509356084 -- ___ 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
[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
[issue37151] Calling code cleanup after PEP 590
Change by Jeroen Demeyer : -- pull_requests: +14418 pull_request: https://github.com/python/cpython/pull/14603 ___ 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
[issue36974] Implement PEP 590
Jeroen Demeyer added the comment: Any objections to closing this? -- ___ 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
[issue37207] Use PEP 590 vectorcall to speed up calls to range(), list() and dict()
Jeroen Demeyer added the comment: One thing that keeps bothering me when using vectorcall for type.__call__ is that we would have two completely independent code paths for constructing an object: the new one using vectorcall and the old one using tp_call, which in turn calls tp_new and tp_init. In typical vectorcall usages, there is no need to support the old way any longer: we can set tp_call = PyVectorcall_Call and that's it. But for "type", we still need to support tp_new and tp_init because there may be C code out there that calls tp_new/tp_init directly. To give one concrete example: collections.defaultdict calls PyDict_Type.tp_init One solution is to keep the old code for tp_new/tp_init. This is what Mark did in PR 13930. But this leads to duplication of functionality and is therefore error-prone (different code paths may have subtly different behaviour). Since we don't want to break Python code calling dict.__new__ or dict.__init__, not implementing those is not an option. But to be compatible with the vectorcall signature, ideally we want to implement __init__ using METH_FASTCALL, so __init__ would need to be a normal method instead of a slot wrapper of tp_init (similar to Python classes). This would work, but it needs some support in typeobject.c -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue37207> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37483] Add PyObject_CallOneArg()
Jeroen Demeyer added the comment: > Jeroen: hum, you both proposed a similar fix :-) It seems that I lost the race ;-) But seriously: if we both independently came up with the same solution, that's a good sign that the solution is correct. -- ___ Python tracker <https://bugs.python.org/issue37483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37483] Add PyObject_CallOneArg()
Change by Jeroen Demeyer : -- pull_requests: +14415 pull_request: https://github.com/python/cpython/pull/14600 ___ Python tracker <https://bugs.python.org/issue37483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29312] Use FASTCALL in dict.update()
Change by Jeroen Demeyer : -- pull_requests: +14407 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14589 ___ 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
[issue37207] Use PEP 590 vectorcall to speed up calls to range(), list() and dict()
Change by Jeroen Demeyer : -- pull_requests: +14406 pull_request: https://github.com/python/cpython/pull/14588 ___ Python tracker <https://bugs.python.org/issue37207> ___ ___ 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: You are correct that PyDict_Merge() does not need to recompute the hashes of the keys. However, your example doesn't work because you need string keys for **kwargs. The "str" class caches its hash, so you would need a dict with a "str" subclass as keys to hit that problem. I think that calling d.update(**kw) with kw having str-subclass keys should be very rare. I'm not sure that we should care about that. -- ___ 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
[issue29312] Use FASTCALL in dict.update()
Jeroen Demeyer added the comment: > How can we avoid unpacking dict in case of d1.update(**d2)? The unpacking is only a problem if you insist on using PyDict_Merge(). It would be perfectly possible to implement dict merging from a tuple+vector instead of from a dict. In that case, there shouldn't be a performance penalty. -- ___ 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
[issue29312] Use FASTCALL in dict.update()
Jeroen Demeyer added the comment: Above, I meant #37207 or PR 13930. -- ___ 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
[issue29312] Use FASTCALL in dict.update()
Jeroen Demeyer added the comment: > How can we avoid unpacking dict in case of d1.update(**d2)? We cannot. However, how common is that call? One could argue that we should optimize for the more common case of d1.update(d2). -- ___ 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
[issue22117] Rewrite pytime.h to work on nanoseconds
Change by Jeroen Demeyer : -- pull_requests: +14405 pull_request: https://github.com/python/cpython/pull/11636 ___ 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
[issue37493] Use _PyObject_CallNoArg() in a few more places
Change by Jeroen Demeyer : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue37493> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29312] Use FASTCALL in dict.update()
Jeroen Demeyer added the comment: For the benefit of PR 37207, I would like to re-open this discussion. It may have been rejected for the wrong reasons. Victor's patch was quite inefficient, but that's to be expected: msg285744 mentions a two-step process, but during the discussion the second steps seems to have been forgotten. -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue29312> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37483] Add PyObject_CallOneArg()
Change by Jeroen Demeyer : -- pull_requests: +14394 pull_request: https://github.com/python/cpython/pull/14575 ___ Python tracker <https://bugs.python.org/issue37483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37483] Add PyObject_CallOneArg()
Jeroen Demeyer added the comment:
Test of stack usage:
from _testcapi import stack_pointer
class D(dict):
def __missing__(self, key):
sp = stack_pointer()
print(f"stack usage = {TOP - sp}")
return None
d = D()
TOP = stack_pointer()
d[0]
**before**: stack usage = 1296
**after**: stack usage = 976
--
___
Python tracker
<https://bugs.python.org/issue37483>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37493] Use _PyObject_CallNoArg() in a few more places
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +14393 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14575 ___ Python tracker <https://bugs.python.org/issue37493> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37493] Use _PyObject_CallNoArg() in a few more places
New submission from Jeroen Demeyer : Try to use _PyObject_CallNoArg in all places where a function is called without arguments. -- components: Interpreter Core messages: 347230 nosy: jdemeyer priority: normal severity: normal status: open title: Use _PyObject_CallNoArg() in a few more places versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue37493> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37483] Add PyObject_CallOneArg()
Jeroen Demeyer added the comment: Victor, what's your opinion on adding PyObject_CallOneArg() to the limited API? -- ___ Python tracker <https://bugs.python.org/issue37483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37483] Add PyObject_CallOneArg()
Jeroen Demeyer added the comment: Stefan: I used an underscore by analogy with PyObject_CallNoArgs()/_PyObject_CallNoArg(), where the first is in the limited API and the second is an inline function in the cpython API. But maybe we could revisit that decision. -- ___ Python tracker <https://bugs.python.org/issue37483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37483] Add PyObject_CallOneArg()
Jeroen Demeyer added the comment: > Is there any benchmark showing if it's faster Here is one example: class D(dict): def __missing__(self, key): return None d = D() and now benchmark d[0] **before**: Mean +- std dev: 173 ns +- 1 ns **after**: Mean +- std dev: 162 ns +- 1 ns To be precise, I ran: ./python -m perf timeit --duplicate 200 -s 'class D(dict):' -s ' def __missing__(self, key):' -s ' return None' -s 'd = D()' 'd[0]' -- ___ Python tracker <https://bugs.python.org/issue37483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37483] Add PyObject_CallOneArg()
Jeroen Demeyer added the comment: > It adds yet another special case underscore function that one cannot use in > external projects. So I would not say that is simpler. If you're worried about the underscore, I will make a separate PR to add a non-underscored version, similar to PyObject_CallNoArgs() -- ___ Python tracker <https://bugs.python.org/issue37483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37483] Add PyObject_CallOneArg()
Jeroen Demeyer added the comment: Exactly. I see no reason to prefer PyObject_CallFunctionObjArgs(func, arg, NULL) over _PyObject_CallOneArg(func, arg) -- ___ Python tracker <https://bugs.python.org/issue37483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37483] Add PyObject_CallOneArg()
Jeroen Demeyer added the comment: > PEP 7 uses C99 since Python 3.6: > https://www.python.org/dev/peps/pep-0007/#c-dialect That's not what the PEP says: "Python versions greater than or equal to 3.6 use C89 with several select C99 features" "several select C99 features" is not the same of using C99. Plus, I'm also worried about C++. We also support compiling C++ extensions with the same header files, so it must be C++ compatible also. -- ___ Python tracker <https://bugs.python.org/issue37483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37483] Add PyObject_CallOneArg()
Jeroen Demeyer added the comment: > _PyObject_CALL_WITH_ARGS(func, PyDict_GetItem(d, key)); // PyDict_GetItem(d, > key) is called twice. Actually, it's not a problem: sizeof() is special, it only looks at the type of its argument, it doesn't execute the code. -- ___ Python tracker <https://bugs.python.org/issue37483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
