Jeroen Demeyer added the comment:
Breakage due to the usage of borrowed references in _PyStack_UnpackDict():
#36907
--
nosy: +jdemeyer
___
Python tracker
<https://bugs.python.org/issue27
New submission from Jeroen Demeyer :
The new flag Py_TPFLAGS_METHOD_DESCRIPTOR proposed in PEP 590 is meant for
classes whose instances behave like unbound methods. In other words, it's meant
for objects supporting the LOAD_METHOD optimization. There are two such classes
in CPython: function
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +13217
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36907>
___
___
Py
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +13218
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36904>
___
___
Py
Jeroen Demeyer added the comment:
I see what you mean now. One bpo issue with many pull requests. I was following
the CPython policy that every pull request needed an issue, but it didn't occur
to me to put multiple independent PRs on one issue.
--
resolution: -> duplicate
st
Change by Jeroen Demeyer :
--
pull_requests: +13397
___
Python tracker
<https://bugs.python.org/issue36974>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeroen Demeyer added the comment:
> Jeroen, do you want to also do a backport for 3.7?
Don't we have a bot for that?
--
___
Python tracker
<https://bugs.python.org/issu
Change by Jeroen Demeyer :
--
pull_requests: +13408
___
Python tracker
<https://bugs.python.org/issue36907>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeroen Demeyer added the comment:
Using __int__ instead of __index__ works. PR coming right away.
--
___
Python tracker
<https://bugs.python.org/issue36
Jeroen Demeyer added the comment:
This is missing a testcase: PR 13461
--
___
Python tracker
<https://bugs.python.org/issue34125>
___
___
Python-bugs-list mailin
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: +13414
___
Python tracker
<https://bugs.python.org/issue36974>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeroen Demeyer added the comment:
Now to justify the naming: the plan is to keep the name "fast call" for the
PyMethodDef flag METH_FASTCALL but to use the name "vectorcall" in the more
general API.
I think that's a good idea regardless of PEP 590,
Jeroen Demeyer added the comment:
> Is it possible to rename Vectorcall, which looks good on its own but not
> inside _PyObject_VectorcallDict()?
I don't understand what you mean here?
> _PyObject_FastCallDict is much easier to read.
You think that "_PyObject_FastCallD
Jeroen Demeyer added the comment:
> I would prefer to wait until the PEP is accepted before starting to push
> changes ;-)
I don't think it's wrong to propose and discuss changes already now. With the
first beta of Python 3.8 getting close, it's better to be prepared already for
the
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +13347
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36970>
___
___
Py
Jeroen Demeyer added the comment:
> From the perspective of reading, it is one of the most obnoxious names I've
> seen in the Python code base.
PyObject_Vectorcall() is the name in PEP 590, so if you want to change it,
better write to python-dev
New submission from Jeroen Demeyer :
As preparation for PEP 590, rename
_PyObject_FastCallKeywords -> _PyObject_Vectorcall
_PyObject_FastCallDict -> _PyObject_VectorcallDict
--
components: Interpreter Core
messages: 342892
nosy: Mark.Shannon, jdemeyer, petr.viktorin
priority:
New submission from Jeroen Demeyer :
The page https://docs.python.org/3/c-api/structures.html could be better
structured by arranging the content in sub-sections.
--
assignee: docs@python
components: Documentation
messages: 342911
nosy: docs@python, jdemeyer
priority: normal
severity
Change by Jeroen Demeyer :
--
components: Interpreter Core
nosy: Mark.Shannon, jdemeyer, petr.viktorin
priority: normal
severity: normal
status: open
title: Implement PEP 590
type: enhancement
versions: Python 3.8
___
Python tracker
<ht
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +13359
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36974>
___
___
Py
Change by Jeroen Demeyer :
--
pull_requests: +13367
___
Python tracker
<https://bugs.python.org/issue36974>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Jeroen Demeyer :
--
pull_requests: +13370
___
Python tracker
<https://bugs.python.org/issue36974>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeroen Demeyer added the comment:
The consensus on PEP 590 now seems to be to keep the name
`_PyObject_FastCallDict` and rename only `_PyObject_FastCallKeywords` ->
`_PyObject_Vectorcall`.
For the record: I don't agree with this decision but I'll implem
Jeroen Demeyer added the comment:
So what are you trying to say? That it *should* be a static function? It most
likely won't be a static function after PEP 590 is fully implemented.
--
___
Python tracker
<https://bugs.python.org/issue36
Jeroen Demeyer added the comment:
In that case, there is no point a making a separate issue or PR.
--
resolution: -> duplicate
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +13375
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36995>
___
___
Py
Change by Jeroen Demeyer :
--
resolution: -> duplicate
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
New submission from Jeroen Demeyer :
If PEP 590 is accepted: in code comments, replace tp_print by
tp_vectorcall_offset and (while we're at it) tp_reserved by tp_as_async.
--
components: Interpreter Core
messages: 343061
nosy: Mark.Shannon, jdemeyer, petr.viktorin
priority: normal
Jeroen Demeyer added the comment:
What's your opinion on renaming also
_PyCFunction_FastCallKeywords -> _PyCFunction_Vectorcall
_PyFunction_FastCallKeywords -> _PyFunction_Vectorcall
If you agree, I will add it to the PR.
--
___
Python t
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +13371
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36994>
___
___
Py
New submission from Jeroen Demeyer :
The branch for profiling a method_descriptor inside do_call_core is not tested
by the test suite.
--
components: Tests
messages: 343044
nosy: jdemeyer
priority: normal
severity: normal
status: open
title: Missing tests for CALL_FUNCTION_EX opcode
Change by Jeroen Demeyer :
--
title: Rename _PyObject_FastCall functions -> Rename _PyObject_FastCallKeywords
___
Python tracker
<https://bugs.python.org/issu
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +13354
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36971>
___
___
Py
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +13267
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36937>
___
___
Py
Jeroen Demeyer added the comment:
I forgot to mention that the idea and first implementation comes from Mark
Shannon.
--
___
Python tracker
<https://bugs.python.org/issue36
New submission from Jeroen Demeyer :
Add a new private function
PyObject *_PyObject_MakeTpCall(PyObject *callable, PyObject *const *args,
Py_ssize_t nargs, PyObject *keywords)
to call "callable" using tp_call, but with arguments given using the
FastCallKeywords or FastCallDict
Jeroen Demeyer added the comment:
> What happens when pass an empty tuple?
The way how bytecode is compiled, that doesn't actually happen so it's an
entirely hypothetical question.
The various XXX_FastCallKeywords functions seem to allow passing an empty tuple
to mean "no keyword a
Jeroen Demeyer added the comment:
Adding that assertion allows future optimizations and simplifications: with the
assertion, "keyword arguments are passed" becomes equivalent to
kwnames != NULL
instead of
kwnames != NULL && PyTuple_GET_SIZE(kwnames) > 0
This ma
New submission from Jeroen Demeyer :
Document and add an assertion that the "keyword names" tuple of the
CALL_FUNCTION_KW opcode must be non-empty. This is already the case with the
current compiler: if there are no keyword arguments in a call, then the
CALL_FUNCTION_KW opcode i
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +13266
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36936>
___
___
Py
Jeroen Demeyer added the comment:
Isn't it a *feature* that those doctest directives are not shown? Those
directives are meant for the doctest module only, not for the reader of the
rendered documentation.
--
nosy: +jdemeyer
___
Python tracker
Jeroen Demeyer added the comment:
> Doctest directives in code examples should be suppressed everywhere *except*
> in the doctest.html examples showing how to use directives.
Thanks for clarifying. I missed that.
--
___
Python tracker
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +13250
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36922>
___
___
Py
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +13252
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36924>
___
___
Py
New submission from Jeroen Demeyer :
The class classmethod_descriptor implements classmethods for builtin functions.
Unlike the plain classmethod class (which is used for Python classmethods),
instances of classmethod_descriptor are callable. However, calling them is
unlikely to happen
Jeroen Demeyer added the comment:
So what's the relation between _PyRuntime and PyInterpreterState? If the latter
is a structure per interpreter, what's the point of also making the former per
interpreter? It would be better to move data from _PyRuntime to
PyInterpreterState
Jeroen Demeyer added the comment:
Changing *every* C API function to include a state parameter looks very
cumbersome. Another alternative would be to store the interpreter state in
every Python object (or every class, that would be sufficient). That way, you
would only need to pass context
Jeroen Demeyer added the comment:
Personally, I have always found "instance" and "owner" very confusing names for
these arguments. If you want to change the documentation, I would recommend
changing those names too. Better names would be "obj"
Jeroen Demeyer added the comment:
FYI: this one-liner installs the crashing versions:
pip3 install git+https://github.com/nickdrozd/astroid.git@crash
git+https://github.com/nickdrozd/pylint.git@crash
--
nosy: +jdemeyer
___
Python tracker
<ht
Jeroen Demeyer added the comment:
> Perhaps the datamodel docs can be clarified to note that callers are allowed
> to omit the third argument
That's not true in general, only when __get__ is a slot wrapper (i.e. for
classes implemented in C). When __get__ is a Python function, n
Jeroen Demeyer added the comment:
What seems to be happening is a recursion error while handling a recursion
error. Essentially
>>> def f():
... try:
... f()
... except:
... f()
...
>>> f()
Fatal Python error: Cannot recover from stack overfl
Jeroen Demeyer added the comment:
> It's wrong to share a single gc state between two interpreters
And what's your solution for that? I'm not asking for a complete
ready-to-implement answer, but at least a basic idea. Otherwise it's impossible
for me to judge whether your PR 12934 he
Jeroen Demeyer added the comment:
> The long term goal is to support multiple interpreter instances per process:
> Eric Snow's PEP 554 "Multiple Interpreters in the Stdlib"
> https://www.python.org/dev/peps/pep-0554/
Sorry, but I don't see the relation between this issue an
Jeroen Demeyer added the comment:
Variadic macros are not part of C89, so that would require changing PEP 7.
--
___
Python tracker
<https://bugs.python.org/issue37
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 th
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 feat
Jeroen Demeyer added the comment:
> Cons: readability...
It's a single relatively short macro. I'm not worried about that. I'm more
about compiler support for such macros. I'll make a PR with this idea and see
what CI says.
--
___
Python trac
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_C
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, s
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
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/issue37
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
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/issu
Change by Jeroen Demeyer :
--
pull_requests: +14406
pull_request: https://github.com/python/cpython/pull/14588
___
Python tracker
<https://bugs.python.org/issue37
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/issu
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**: s
Jeroen Demeyer added the comment:
Victor, what's your opinion on adding PyObject_CallOneArg() to the limited API?
--
___
Python tracker
<https://bugs.python.org/issue37
Change by Jeroen Demeyer :
--
pull_requests: +14415
pull_request: https://github.com/python/cpython/pull/14600
___
Python tracker
<https://bugs.python.org/issue37
Change by Jeroen Demeyer :
--
pull_requests: +14418
pull_request: https://github.com/python/cpython/pull/14603
___
Python tracker
<https://bugs.python.org/issue37
Jeroen Demeyer added the comment:
Any objections to closing this?
--
___
Python tracker
<https://bugs.python.org/issue36974>
___
___
Python-bugs-list mailin
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 corr
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
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 trac
Jeroen Demeyer added the comment:
Above, I meant #37207 or PR 13930.
--
___
Python tracker
<https://bugs.python.org/issue29312>
___
___
Python-bugs-list mailin
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 c
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&qu
Jeroen Demeyer added the comment:
> If you modify code which can impact test_gdb, you can run test_gdb locally
I do run test_gdb locally but it's not very useful since most tests are skipped
by default because python_is_optimized() is True. That's the whole point of
this issue: te
Jeroen Demeyer added the comment:
> Depending on the compiler optimization level, gdb may or may not br able to
> read variables and function arguments.
I haven't seen that problem. As I said, all GDB tests pass when compiled with
"-O3 -g".
> IHMO it is fine to skip
Jeroen Demeyer added the comment:
Feel free to close...
--
nosy: +jdemeyer
___
Python tracker
<https://bugs.python.org/issue33926>
___
___
Python-bugs-list m
Jeroen Demeyer added the comment:
I meant this part in test_gdb.py:
if ((sysconfig.get_config_var('PGO_PROF_USE_FLAG') or 'xxx') in
(sysconfig.get_config_var('PY_CORE_CFLAGS') or '')):
raise unittest.SkipTest("test_gdb is not reliable on PGO b
Jeroen Demeyer added the comment:
> The worst debugging experience is provided by PGO build.
That's true but unrelated to this issue. We already skip test_gdb completely
when PGO is enabled.
--
___
Python tracker
<https://bugs.pyth
Change by Jeroen Demeyer :
--
pull_requests: +14209
pull_request: https://github.com/python/cpython/pull/14395
___
Python tracker
<https://bugs.python.org/issue37
Jeroen Demeyer added the comment:
These python_is_optimized() tests were added in #8605 and #13628. Those issues
talk about tests failing when CPython is compiled with -O2 or -O3. But, as I
said here, I see no problems today with gcc -O3. So I'm guessing that either
gcc or gdb improved
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/issu
Change by Jeroen Demeyer :
--
pull_requests: +14490
pull_request: https://github.com/python/cpython/pull/14684
___
Python tracker
<https://bugs.python.org/issue37
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
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
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
Change by Jeroen Demeyer :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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/issue37
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
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
Change by Jeroen Demeyer :
--
resolution: -> wont fix
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +14374
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/14558
___
Python tracker
<https://bugs.python.org/issu
Change by Jeroen Demeyer :
--
pull_requests: +14394
pull_request: https://github.com/python/cpython/pull/14575
___
Python tracker
<https://bugs.python.org/issue37
Change by Jeroen Demeyer :
--
pull_requests: +14405
pull_request: https://github.com/python/cpython/pull/11636
___
Python tracker
<https://bugs.python.org/issue22
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
Change by Jeroen Demeyer :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Jeroen Demeyer added the comment:
> Python's exception mechanism is a much better way to signal and handle such
> errors at the application level.
I disagree. There is a difference between exceptions which are possible in
normal usage of the code and real bugs, which shouldn't ever
401 - 500 of 586 matches
Mail list logo
