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/issu
Change by Jeroen Demeyer :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Jeroen Demeyer :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Jeroen Demeyer added the comment:
Superseded by PR 13781
--
resolution: -> duplicate
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Jeroen Demeyer :
--
pull_requests: +14333
pull_request: https://github.com/python/cpython/pull/14517
___
Python tracker
<https://bugs.python.org/issue36
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 intermediat
Jeroen Demeyer added the comment:
See also
https://github.com/python/cpython/pull/14193#pullrequestreview-251630953
--
nosy: +jdemeyer
___
Python tracker
<https://bugs.python.org/issue37
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
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
___
Py
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
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
Jeroen Demeyer added the comment:
PR 14782 (backport of PR 13781) fixes the regression for me.
--
___
Python tracker
<https://bugs.python.org/issue37
Change by Jeroen Demeyer :
--
pull_requests: +14578
pull_request: https://github.com/python/cpython/pull/14782
___
Python tracker
<https://bugs.python.org/issue36
Change by Jeroen Demeyer :
--
pull_requests: +14579
pull_request: https://github.com/python/cpython/pull/14782
___
Python tracker
<https://bugs.python.org/issue37
Change by Jeroen Demeyer :
--
versions: -Python 3.9
___
Python tracker
<https://bugs.python.org/issue37562>
___
___
Python-bugs-list mailing list
Unsubscribe:
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/issu
Change by Jeroen Demeyer :
--
pull_requests: -14235
___
Python tracker
<https://bugs.python.org/issue32926>
___
___
Python-bugs-list mailing list
Unsubscribe:
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/issu
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
Change by Jeroen Demeyer :
--
pull_requests: +14367
pull_request: https://github.com/python/cpython/pull/14550
___
Python tracker
<https://bugs.python.org/issue37
Change by Jeroen Demeyer :
--
pull_requests: +14368
pull_request: https://github.com/python/cpython/pull/14550
___
Python tracker
<https://bugs.python.org/issue37
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
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 e
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/issu
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 track
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 i
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
<ht
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. Ther
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-rati
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(
Change by Jeroen Demeyer :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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
Change by Jeroen Demeyer :
--
pull_requests: +15018
pull_request: https://github.com/python/cpython/pull/15295
___
Python tracker
<https://bugs.python.org/issue37
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/issu
Change by Jeroen Demeyer :
--
pull_requests: +15046
pull_request: https://github.com/python/cpython/pull/15328
___
Python tracker
<https://bugs.python.org/issue37
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/issu
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.pyth
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
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 f
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
___
Pyt
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
<
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 fract
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 libr
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
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
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 t
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(*
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 +-
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,
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/issu
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
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
Change by Jeroen Demeyer :
--
nosy: +jdemeyer
___
Python tracker
<https://bugs.python.org/issue37934>
___
___
Python-bugs-list mailing list
Unsubscribe:
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/issue37
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
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_ov
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/issu
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/issu
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
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
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/issue11
Jeroen Demeyer added the comment:
I agree with rejecting and closing this issue.
--
nosy: +jdemeyer
___
Python tracker
<https://bugs.python.org/issue33
Jeroen Demeyer added the comment:
Please close
--
___
Python tracker
<https://bugs.python.org/issue37562>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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/issu
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
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/issu
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,
Jeroen Demeyer added the comment:
4. It uses the __name__ instead of the __qualname__
--
___
Python tracker
<https://bugs.python.org/issue37645>
___
___
Pytho
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: jdemeye
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/issu
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/i
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/issue37
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/issu
Change by Jeroen Demeyer :
--
pull_requests: +14600
pull_request: https://github.com/python/cpython/pull/14804
___
Python tracker
<https://bugs.python.org/issue29
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
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/issu
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/issu
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
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/issu
Change by Jeroen Demeyer :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Jeroen Demeyer :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Jeroen Demeyer :
--
pull_requests: +14488
pull_request: https://github.com/python/cpython/pull/14683
___
Python tracker
<https://bugs.python.org/issue29
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
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/issue40
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/issu
501 - 586 of 586 matches
Mail list logo
