[issue40608] PY3.8 GC segfault (Py_TRASHCAN_SAFE_BEGIN/END are not backwards compatible)

2020-05-12 Thread Jeroen Demeyer


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

2019-09-11 Thread Jeroen Demeyer


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

2019-09-10 Thread Jeroen Demeyer


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

2019-09-04 Thread Jeroen Demeyer


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()

2019-08-26 Thread Jeroen Demeyer


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

2019-08-24 Thread Jeroen Demeyer


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()

2019-08-23 Thread Jeroen Demeyer


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()

2019-08-22 Thread Jeroen Demeyer


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

2019-08-22 Thread Jeroen Demeyer


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

2019-08-22 Thread Jeroen Demeyer


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()

2019-08-20 Thread Jeroen Demeyer


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()

2019-08-20 Thread Jeroen Demeyer


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()

2019-08-19 Thread Jeroen Demeyer


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()

2019-08-19 Thread Jeroen Demeyer


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

2019-08-19 Thread Jeroen Demeyer


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()

2019-08-19 Thread Jeroen Demeyer


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

2019-08-19 Thread Jeroen Demeyer


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

2019-08-18 Thread Jeroen Demeyer


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

2019-08-18 Thread Jeroen Demeyer


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

2019-08-17 Thread Jeroen Demeyer


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

2019-08-17 Thread Jeroen Demeyer


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

2019-08-16 Thread Jeroen Demeyer


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

2019-08-14 Thread Jeroen Demeyer


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

2019-08-14 Thread Jeroen Demeyer


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

2019-08-14 Thread Jeroen Demeyer


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

2019-08-13 Thread Jeroen Demeyer


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

2019-08-13 Thread Jeroen Demeyer


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

2019-08-13 Thread Jeroen Demeyer


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

2019-08-13 Thread Jeroen Demeyer


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

2019-08-13 Thread Jeroen Demeyer


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

2019-08-13 Thread Jeroen Demeyer


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

2019-08-13 Thread Jeroen Demeyer


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()

2019-08-12 Thread Jeroen Demeyer


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

2019-08-07 Thread Jeroen Demeyer


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

2019-08-07 Thread Jeroen Demeyer


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

2019-08-06 Thread Jeroen Demeyer


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

2019-08-06 Thread Jeroen Demeyer


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

2019-08-05 Thread Jeroen Demeyer


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

2019-08-05 Thread Jeroen Demeyer


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

2019-08-05 Thread Jeroen Demeyer


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

2019-08-05 Thread Jeroen Demeyer


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

2019-08-04 Thread Jeroen Demeyer


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__

2019-08-04 Thread Jeroen Demeyer


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

2019-07-21 Thread Jeroen Demeyer


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

2019-07-21 Thread Jeroen Demeyer


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

2019-07-21 Thread Jeroen Demeyer


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

2019-07-19 Thread Jeroen Demeyer


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

2019-07-19 Thread Jeroen Demeyer


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

2019-07-19 Thread Jeroen Demeyer


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

2019-07-18 Thread Jeroen Demeyer


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

2019-07-18 Thread Jeroen Demeyer


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

2019-07-17 Thread Jeroen Demeyer


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

2019-07-17 Thread Jeroen Demeyer


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

2019-07-16 Thread Jeroen Demeyer


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

2019-07-15 Thread Jeroen Demeyer


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

2019-07-15 Thread Jeroen Demeyer


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

2019-07-15 Thread Jeroen Demeyer


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

2019-07-15 Thread Jeroen Demeyer


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

2019-07-15 Thread Jeroen Demeyer


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

2019-07-15 Thread Jeroen Demeyer


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

2019-07-12 Thread Jeroen Demeyer


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

2019-07-11 Thread Jeroen Demeyer


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

2019-07-11 Thread Jeroen Demeyer


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()

2019-07-11 Thread Jeroen Demeyer


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()

2019-07-10 Thread Jeroen Demeyer


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()

2019-07-10 Thread Jeroen Demeyer


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

2019-07-10 Thread Jeroen Demeyer


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

2019-07-10 Thread Jeroen Demeyer


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__

2019-07-10 Thread Jeroen Demeyer


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()

2019-07-10 Thread Jeroen Demeyer


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

2019-07-10 Thread Jeroen Demeyer


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

2019-07-10 Thread Jeroen Demeyer


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()

2019-07-09 Thread Jeroen Demeyer


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()

2019-07-08 Thread Jeroen Demeyer


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

2019-07-05 Thread Jeroen Demeyer


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

2019-07-05 Thread Jeroen Demeyer


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()

2019-07-05 Thread Jeroen Demeyer


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()

2019-07-05 Thread Jeroen Demeyer


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()

2019-07-05 Thread Jeroen Demeyer


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()

2019-07-04 Thread Jeroen Demeyer


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()

2019-07-04 Thread Jeroen Demeyer


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()

2019-07-04 Thread Jeroen Demeyer


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()

2019-07-04 Thread Jeroen Demeyer


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()

2019-07-04 Thread Jeroen Demeyer


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()

2019-07-04 Thread Jeroen Demeyer


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

2019-07-04 Thread Jeroen Demeyer


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

2019-07-04 Thread Jeroen Demeyer


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()

2019-07-04 Thread Jeroen Demeyer


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()

2019-07-03 Thread Jeroen Demeyer


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()

2019-07-03 Thread Jeroen Demeyer


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

2019-07-03 Thread Jeroen Demeyer


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

2019-07-03 Thread Jeroen Demeyer


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()

2019-07-03 Thread Jeroen Demeyer


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()

2019-07-03 Thread Jeroen Demeyer


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()

2019-07-03 Thread Jeroen Demeyer


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()

2019-07-03 Thread Jeroen Demeyer


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()

2019-07-03 Thread Jeroen Demeyer


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()

2019-07-03 Thread Jeroen Demeyer


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()

2019-07-03 Thread Jeroen Demeyer


Jeroen Demeyer  added the comment:

> _PyObject_CALL_WITH_ARGS(func, PyDict_GetItem(d, key)); // PyDict_GetItem(d, 
> key) is called twice.

Actually, it's not a problem: sizeof() is special, it only looks at the type of 
its argument, it doesn't execute the code.

--

___
Python tracker 
<https://bugs.python.org/issue37483>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue37483] Add PyObject_CallOneArg()

2019-07-03 Thread Jeroen Demeyer


Jeroen Demeyer  added the comment:

> _PyObject_CALL_WITH_ARGS(func, PyDict_GetItem(d, key)); // PyDict_GetItem(d, 
> key) is called twice.

That's pretty bad and in my opinion a good reason to reject this idea.

> If two or more arguments are not common, I prefer _PyObject_CallOneArg to 
> macro.

I posted some counts at 
https://mail.python.org/archives/list/capi-...@python.org/message/3I76R27YMFSKB5JQIM3E4NA3BECVTZHP/

--

___
Python tracker 
<https://bugs.python.org/issue37483>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



  1   2   3   4   5   6   >