Jeroen Demeyer added the comment:
> The sentence doesn't talk about the MRO of *type* (the first argument),
it talks about the __mro__ attribute.
If you have to explain in a bpo issue how the doc should be read, that proves
exactly my point that it's confusing. The fact that i
Jeroen Demeyer added the comment:
> Only one of the two arguments is called "type". The other is called
"object-or-type".
I'm having problems with the first word of "a parent or sibling class of type".
The most important part of super() is to *wh
Jeroen Demeyer added the comment:
> What more do you want?
Mainly: it says "a parent or sibling class of *type*" but it doesn't explain
which class it actually uses.
And the sentence "The __mro__ attribute of the type lists the method resolution
search order us
Jeroen Demeyer added the comment:
I opened another doc issue about super(): #37176
--
nosy: +jdemeyer
___
Python tracker
<https://bugs.python.org/issue18
New submission from Jeroen Demeyer :
The documentation for super() at
https://docs.python.org/3.8/library/functions.html#super does not actually say
what super() does. It only says "Return a proxy object that delegates method
calls to a parent or sibling class of type" and then giv
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +13743
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/13867
___
Python tracker
<https://bugs.python.org/issu
Jeroen Demeyer added the comment:
That's entirely my fault. I was not aware of the fact that calling memcpy()
with src=NULL and length 0 was undefined behaviour. I disagree that it should
be undefined, but there is not much point in arguing against the C standard.
--
nosy: +jdemeyer
Change by Jeroen Demeyer :
--
pull_requests: +13741
pull_request: https://github.com/python/cpython/pull/13865
___
Python tracker
<https://bugs.python.org/issue36
Change by Jeroen Demeyer :
--
pull_requests: +13740
pull_request: https://github.com/python/cpython/pull/13864
___
Python tracker
<https://bugs.python.org/issue37
Change by Jeroen Demeyer :
--
pull_requests: +13733
pull_request: https://github.com/python/cpython/pull/13858
___
Python tracker
<https://bugs.python.org/issue36
Change by Jeroen Demeyer :
--
pull_requests: +13721
pull_request: https://github.com/python/cpython/pull/13844
___
Python tracker
<https://bugs.python.org/issue36
Jeroen Demeyer added the comment:
Right, but my question was very specifically about a test added for this issue.
So asking it here first made sense to me. If nobody would reply, I could still
ask somewhere else.
In the end, Petr solved the problem anyway, so the question is irrelevant now
Jeroen Demeyer added the comment:
> Commenting closed issues is not the most efficient way to get an answer ;-)
Serious question: why is that? I got an email from bugs.python.org with your
comment, so why should commenting on closed issues be any worse than commenting
on open iss
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +13694
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/13340
___
Python tracker
<https://bugs.python.org/issu
Jeroen Demeyer added the comment:
I opened a more general issue #37151
--
___
Python tracker
<https://bugs.python.org/issue36924>
___
___
Python-bugs-list mailin
New submission from Jeroen Demeyer :
Now that PEP 590 has been implemented, a lot of old code can be cleaned up. In
particular:
- get rid of _PyMethodDef_RawFastCallXXX() functions and replace them by
vectorcall functions for each calling convention
- get rid of FastCallDict
Change by Jeroen Demeyer :
--
pull_requests: +13666
pull_request: https://github.com/python/cpython/pull/13781
___
Python tracker
<https://bugs.python.org/issue36
Change by Jeroen Demeyer :
--
pull_requests: +13569
pull_request: https://github.com/python/cpython/pull/13682
___
Python tracker
<https://bugs.python.org/issue36
Jeroen Demeyer added the comment:
Testsuite breakage: https://bugs.python.org/issue37098
--
nosy: +jdemeyer
___
Python tracker
<https://bugs.python.org/issue26
New submission from Jeroen Demeyer :
On an older Linux system:
==
ERROR: test_memfd_create (test.test_os.MemfdCreateTests)
--
Traceback (most recent call last
New submission from Jeroen Demeyer :
The function python_is_optimized() in Lib/test/support.py:
def python_is_optimized():
"""Find if Python was built with optimizations."""
cflags = sysconfig.get_config_var('PY_CFLAGS') or ''
final_opt =
Jeroen Demeyer added the comment:
Petr claims to have a fix, https://github.com/python/cpython/pull/13665
--
___
Python tracker
<https://bugs.python.org/issue22
Jeroen Demeyer added the comment:
Can somebody here explain the meaning of the comment in test_gdb.py
# Tested function must not be defined with METH_NOARGS or METH_O,
# otherwise call_function() doesn't call PyCFunction_Call()
This test is breaking with PEP 590, see
https://github.com
Change by Jeroen Demeyer :
--
pull_requests: +13547
pull_request: https://github.com/python/cpython/pull/13653
___
Python tracker
<https://bugs.python.org/issue36
Change by Jeroen Demeyer :
--
pull_requests: +13414
___
Python tracker
<https://bugs.python.org/issue36974>
___
___
Python-bugs-list mailing list
Unsubscribe:
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:
> 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 :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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 :
--
pull_requests: +13397
___
Python tracker
<https://bugs.python.org/issue36974>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 :
--
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
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
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 :
--
pull_requests: +13370
___
Python tracker
<https://bugs.python.org/issue36974>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Jeroen Demeyer :
--
pull_requests: +13367
___
Python tracker
<https://bugs.python.org/issue36974>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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:
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
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +13359
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36974>
___
___
Py
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: +13354
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36971>
___
___
Py
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
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
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
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
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +13347
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36970>
___
___
Py
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:
Change by Jeroen Demeyer :
--
pull_requests: +13292
___
Python tracker
<https://bugs.python.org/issue36907>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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:
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
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
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:
> 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
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
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +13266
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36936>
___
___
Py
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: +13254
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36926>
___
___
Py
New submission from Jeroen Demeyer :
Once PEP 590 is implemented, it makes sense to focus on using the new
"vectorcall" calling convention, which is essentially what is currently
FastCallKeywords. To simplify things, it would also be good to use FastCallDict
in as few places a
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
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +13250
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36922>
___
___
Py
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
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
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +13218
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36904>
___
___
Py
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +13217
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36907>
___
___
Py
Jeroen Demeyer added the comment:
The idea of #36904 could be used here: define a special kind of tuple, which is
like an ordinary tuple followed by a C array of PyObject* entries (all
refcounted), terminated by a NULL to know where it ends. A special deallocation
function would decref all
Jeroen Demeyer added the comment:
Ideally, this would be fixed together with #36904.
--
___
Python tracker
<https://bugs.python.org/issue36907>
___
___
Pytho
Change by Jeroen Demeyer :
--
components: +Interpreter Core -Library (Lib)
___
Python tracker
<https://bugs.python.org/issue36904>
___
___
Python-bugs-list mailin
Jeroen Demeyer added the comment:
Ideally, this would be fixed together with #36907.
--
___
Python tracker
<https://bugs.python.org/issue36904>
___
___
Pytho
Change by Jeroen Demeyer :
--
type: -> crash
___
Python tracker
<https://bugs.python.org/issue36907>
___
___
Python-bugs-list mailing list
Unsubscrib
New submission from Jeroen Demeyer :
class IntWithDict:
def __init__(self, **kwargs):
self.kwargs = kwargs
def __index__(self):
self.kwargs.clear()
L = [2**i for i in range(1)]
return 0
x = IntWithDict(dont_inherit=float())
compile("",
Change by Jeroen Demeyer :
--
nosy: +vstinner
___
Python tracker
<https://bugs.python.org/issue36904>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Jeroen Demeyer :
_PyStack_UnpackDict() is used to convert from the FastCallDict calling
convention to FastCallKeywords. It currently needs two allocations: one for the
tuple of keyword names and one for the array of arguments (positional and
keyword).
This can
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:
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:
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:
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:
> 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:
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:
> 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:
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:
The gain is small, but it's there.
I made some further changes:
- replacing code of the form
sp = stack_pointer;
call_function(..., , ...)
stack_pointer = sp;
by
call_function(..., _pointer, ...)
- fold the inline function do_call_core
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +12764
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36616>
___
___
Py
Jeroen Demeyer added the comment:
Mark, Petr, do you agree? I like the way how the reference implementation of
PEP 590 improves the handling of profiling. However, that change really has
little to do with PEP 590, it's something that we can do independently
Change by Jeroen Demeyer :
--
type: -> performance
___
Python tracker
<https://bugs.python.org/issue36616>
___
___
Python-bugs-list mailing list
Unsubscrib
New submission from Jeroen Demeyer :
The bytecode interpreter uses an inline function call_function() to handle most
function calls. To check for profiling, call_function() needs to call to
PyThreadState_GET().
In the reference implementation of PEP 590, I saw that we can remove
Jeroen Demeyer added the comment:
> signalmodule.c has a hack to limit it to the main thread.
The Python signal handler always runs in the main thread, but the signal can be
caught by any thread. In other words, trip_signal() can be run by any thr
Jeroen Demeyer added the comment:
Also note that the documentation of the signal module already has the correct
wording:
Python signal handlers are always executed in the main Python thread, even if
the signal was received in another thread
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +12711
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36601>
___
___
Py
New submission from Jeroen Demeyer :
Because of some discussion that is happening on #1583 I noticed this bit of
code in the OS-level signal handler (set by the C function sigaction() or
signal()):
static void
signal_handler(int sig_num)
{
/* See NOTES section above */
if (getpid
Jeroen Demeyer added the comment:
> signal-safe is different from thread-safe
I know, but I think that other threads can receive signals too. So in that
case, it needs to be signal-safe as well as thread-safe.
--
___
Python tracker
<
201 - 300 of 586 matches
Mail list logo
