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
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.
--
___
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
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 :
--
resolution: -> wont fix
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +14373
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/14557
___
Python tracker
<https://bugs.python.org/issu
New submission from Jeroen Demeyer :
35% of all cases where methods are called without PY_VECTORCALL_ARGUMENT_OFFSET
and taking at least 1 argument (positional or keyword) are calls to __exit__
So we should really optimize __exit__
--
components: Interpreter Core
messages: 347139
New submission from Jeroen Demeyer :
As discussed in
https://mail.python.org/archives/list/capi-...@python.org/thread/X6HJOEX6RRFLNKAQSQR6HLD7K4QZ4OTZ/
it would be convenient to have a function PyObject_CallOneArg() for making
calls with exactly 1 positional argument and no keyword arguments
Change by Jeroen Demeyer :
--
pull_requests: +14367
pull_request: https://github.com/python/cpython/pull/14550
___
Python tracker
<https://bugs.python.org/issue37
Change by Jeroen Demeyer :
--
pull_requests: +14368
pull_request: https://github.com/python/cpython/pull/14550
___
Python tracker
<https://bugs.python.org/issue37
Jeroen Demeyer added the comment:
> if a change like that is pushed, all the fleet has to be monitored for
> potential failures, as there are many older OSes supported there.
If this breaks some buildbots, then we can find out more precisely under which
conditions they fail. For examp
Change by Jeroen Demeyer :
--
pull_requests: +14333
pull_request: https://github.com/python/cpython/pull/14517
___
Python tracker
<https://bugs.python.org/issue36
Change by Jeroen Demeyer :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Jeroen Demeyer :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Jeroen Demeyer added the comment:
Superseded by PR 13781
--
resolution: -> duplicate
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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&#x
Jeroen Demeyer added the comment:
Feel free to close...
--
nosy: +jdemeyer
___
Python tracker
<https://bugs.python.org/issue33926>
___
___
Python-bugs-list m
Change by Jeroen Demeyer :
--
pull_requests: -14235
___
Python tracker
<https://bugs.python.org/issue32926>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Jeroen Demeyer :
--
pull_requests: +14235
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/14395
___
Python tracker
<https://bugs.python.org/issu
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +14234
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/14395
___
Python tracker
<https://bugs.python.org/issu
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +14233
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/14395
___
Python tracker
<https://bugs.python.org/issu
Jeroen Demeyer added the comment:
> Maybe open an issue to attempt to install gdb on Travis CI?
I created PR 14395 for this.
--
___
Python tracker
<https://bugs.python.org/issu
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
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
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:
> 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
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 iss
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 ski
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +14151
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/14331
___
Python tracker
<https://bugs.python.org/issu
Jeroen Demeyer added the comment:
The tests FAIL when CPython is compiled with "-O0 -g0" (without optimizations,
without debug info) but tests PASS when compiled with "-O3 -g", showing that
the check for "-g" is the right one.
--
Change by Jeroen Demeyer :
--
pull_requests: +14150
pull_request: https://github.com/python/cpython/pull/14330
___
Python tracker
<https://bugs.python.org/issue20
New submission from Jeroen Demeyer :
Many tests in test_gdb are not run if python_is_optimized() is true. However,
it's not entirely clear why we have this condition. For example, on my system,
with the default CPython configuration, Python *is* optimized but still all gdb
tests pass
Jeroen Demeyer added the comment:
Never mind, I probably tested wrong here.
--
resolution: -> works for me
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Jeroen Demeyer added the comment:
> based on precedents that do not apply to this situation
I'm curious what you mean here...
--
___
Python tracker
<https://bugs.python.org
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +14106
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/14284
___
Python tracker
<https://bugs.python.org/issu
New submission from Jeroen Demeyer :
functools.partial already has some optimizations to use vectorcall (formerly
known as fastcall) for its onward calls, so it makes a lot of sense to also use
vectorcall when being called.
--
components: Library (Lib)
messages: 346193
nosy
Jeroen Demeyer added the comment:
> Is four months really an unreasonable timeline? I thought most of these
> packages released more frequently than CPython.
I'm mostly worried about dependency chains. Right now, any project which
depends on numpy cannot even test on 3.8b1 be
Jeroen Demeyer added the comment:
> Perhaps it would be helpful for someone to recap the current options on the
> table for moving forward and the most significant risk to Cython, Projects
> using Cython, or CPython by selecting each option.
There are three options:
(1) Status-
Jeroen Demeyer added the comment:
If we're in doubt, we should just apply PR 14193. It's essentially a one-line
patch that fixes actual problems experienced by users and which doesn't break
anything. Why should we *not* apply it?
I know that we're not obliged to fix a
Jeroen Demeyer added the comment:
Can we then bring back the discussion to the core of this issue: should we
restore tp_print or not in PyTypeObject?
Note that the PR for the other similar issue #37221 has been accepted for
merging
Change by Jeroen Demeyer :
--
pull_requests: -13873
___
Python tracker
<https://bugs.python.org/issue37221>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Jeroen Demeyer :
--
pull_requests: +14095
pull_request: https://github.com/python/cpython/pull/14269
___
Python tracker
<https://bugs.python.org/issue37
Change by Jeroen Demeyer :
--
pull_requests: +14093
pull_request: https://github.com/python/cpython/pull/14267
___
Python tracker
<https://bugs.python.org/issue37
Jeroen Demeyer added the comment:
The fact that tp_vectorcall_offset replaces tp_print was a very conscious
decision that we made already when designing the PEPs (both PEP 580 and PEP
590). We shouldn't just throw that away without a good reason.
So far I haven't seen any good re
Jeroen Demeyer added the comment:
> This isn't a supported scenario though.
Of course it's not! I was trying to tell you that already in msg345969 but you
insisted in msg345988 that we should support that anyway.
--
___
Python tr
Jeroen Demeyer added the comment:
> We haven't released vectorcall yet, so it has no compatibility baseline.
I'm talking about the "extremely unlikely" scenario mentioned earlier: a class
compiled with 3.7 could subclass a class compiled with 3.8
Jeroen Demeyer added the comment:
> If compatibility is the concern here, then we should be aiming for the
> smallest diff between 3.7 and 3.8
I challenge that assertion.
The smallest diff may superficially look like the best solution, but on closer
inspection, it is not. It will bre
Jeroen Demeyer added the comment:
> If we should put in the workaround for 3.8, how does that make it okay to
> remove in 3.9?
I can easily change my PR to keep it in 3.9, no problem. Nick, what do you
think?
> put the new field at the end and leave the deprecated one exactly
Change by Jeroen Demeyer :
--
nosy: +jdemeyer
___
Python tracker
<https://bugs.python.org/issue36231>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeroen Demeyer added the comment:
Are the benchmark results that you posted above for removing the free list
completely or for the one-element free list as in PR 14232?
--
___
Python tracker
<https://bugs.python.org/issue37
Jeroen Demeyer added the comment:
> GH-14232 uses only one free object instead of at most 256 free list.
That sounds like a compromise which is worse than either extreme: it's worse
than no free list because you still have the overhead of dealing with the one
object. And it's
Jeroen Demeyer added the comment:
> I will run pyperformance again after bpo-37337 is merged.
Good idea. bpo-37337 removes many calls of _PyObject_CallMethodId() which does
NOT use the LOAD_METHOD optimization.
--
___
Python tracker
<
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +14064
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/14228
___
Python tracker
<https://bugs.python.org/issu
New submission from Jeroen Demeyer :
To augment the various PyObject_CallMethod...() functions, we add
_PyObject_VectorcallMethod() which uses the vectorcall calling convention. To
be consistent with the other vectorcall functions, this function is provisional
for now.
For efficiency, the
Jeroen Demeyer added the comment:
Personally, I don't think that your "read of it" in #msg345990 is relevant to
the discussion of the PR (I don't mean this in a bad way).
It's one thing to say "we're not obliged to fix this" (I agree with that) but
t
Jeroen Demeyer added the comment:
I would argue for the pragmatic solution: PR 14193 fixes that old
Cython-generated code. More generally, it fixes API compatibility and doesn't
make ABI compatibility worse than the status quo (the proposal of putting back
tp_print in pla
Jeroen Demeyer added the comment:
> Oh? In that case, let's just remove the reserved/deprecated field :)
Don't confuse *ABI* and *API* compatibility. For *API* compatibility, it
doesn't matter where we put tp_print.
--
___
Pyth
Change by Jeroen Demeyer :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Jeroen Demeyer added the comment:
All PRs currently on this issue have been merged, but this is not finished yet.
I'm mainly waiting for a resolution on PR 13781 because that's a big change
which needs to be done before furth
Jeroen Demeyer added the comment:
> If we reintroduce it, why not put it back at its previous place, to provide
> ABI compatibility?
First of all, we longer care about ABI compatibility of PyTypeObject.
Second, it is extremely unlikely that the class will use vectorcall: the only
way
Change by Jeroen Demeyer :
--
title: C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print
removed, replaced with tp_vectorcall_offset -> C files generated by Cython set
tp_print to 0: PyTypeObject.tp_print removed
___
Pyt
Jeroen Demeyer added the comment:
> IMHO the simplest and safest option for this issue is to revert tp_print
> removal and move tp_vectorcall_offset at the end of PyTypeObject.
I just realized that there is a much simpler solution: add back tp_print at the
*end* of the PyType
Change by Jeroen Demeyer :
--
pull_requests: +14030
pull_request: https://github.com/python/cpython/pull/14193
___
Python tracker
<https://bugs.python.org/issue37
Change by Jeroen Demeyer :
--
pull_requests: +13996
pull_request: https://github.com/python/cpython/pull/14153
___
Python tracker
<https://bugs.python.org/issue37
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +13938
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/14079
___
Python tracker
<https://bugs.python.org/issu
Jeroen Demeyer added the comment:
Victor, of the four functions you mentioned:
- _PyObject_FastCallDict: documented by PEP 590
- _PyObject_FastCallKeywords: renamed _PyObject_Vectorcall and documented by
PEP 590
- _PyObject_FastCall: not sure if it's useful enough (jus
Jeroen Demeyer added the comment:
Why is it that __init__ is called multiple times? I'm just wondering if we
could somehow ensure that __init__ is called only once.
--
nosy: +jdemeyer
___
Python tracker
<https://bugs.python.org/is
Jeroen Demeyer added the comment:
> I would argue the sequence doesn't really matter that much for non SWIG
> packages
I don't think that this is correct. Or at least, it's not obvious to me that
this is correct. It's not uncommon for projects to extend distutil
Jeroen Demeyer added the comment:
> This is a terrible idea, FWIW. Please don't do this.
Why not? It's a simple pragmatic solution that fixes an actual problem at
essentially no cost to CPython.
You're right of course that Cython shouldn't set tp_print to 0 on Pytho
Jeroen Demeyer added the comment:
> The two are related, no?
Related in the same way that tp_dictoffset and tp_dict are related (i.e. not
that much).
--
___
Python tracker
<https://bugs.python.org/issu
Jeroen Demeyer added the comment:
> Honestly, reintroducing tp_print looks simple and safe enough. Is there any
> drawback?
1. The one-time effort to change the code and documentation back.
2. Stefan Behnel wanted to use tp_print for backporting vectorcall in Cython to
earlier
Jeroen Demeyer added the comment:
> This code can cause subtle and annoying issue if PR 13858 is merged.
Or maybe you're confusing tp_vectorcall_offset and tp_vectorcall again?
--
___
Python tracker
<https://bugs.python.org
Jeroen Demeyer added the comment:
> If we decide to not reintroduce tp_print, tp_print removal must be documented
> at:
https://docs.python.org/dev/whatsnew/3.8.html#changes-in-the-c-api
I'll add that to PR 13844.
--
___
Python trac
Jeroen Demeyer added the comment:
> This code can cause subtle and annoying issue if PR 13858 is merged.
I don't see how this is related to PR 13858 at all. Please explain.
--
___
Python tracker
<https://bugs.python.org
Jeroen Demeyer added the comment:
> IMHO the simplest and safest option for this issue is to revert tp_print
> removal and move tp_vectorcall_offset at the end of PyTypeObject.
That's a drastic solution to a rather simple problem. PR 14009 would fix Cython
Jeroen Demeyer added the comment:
> I understand that tp_vectorcall_offset=0 is fine and the expected value for a
> type which doesn't have the flag _Py_TPFLAGS_HAVE_VECTORCALL.
Not necessarily. There are subtleties involved when subclassing: there are
cases where tp_vectorcall_o
Jeroen Demeyer added the comment:
> If -Werror is used, "type->tp_vectorcall = NULL;" would fail with a
> compilation error, since NULL is not exactly an integer, no?
No because tp_vectorcall is a function pointer. You're confusing with
tp_vectorcall_of
Jeroen Demeyer added the comment:
Actually, Cython generates code setting tp_print to 0 (not NULL).
--
nosy: +jdemeyer
___
Python tracker
<https://bugs.python.org/issue37
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +13880
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/14009
___
Python tracker
<https://bugs.python.org/issu
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +13879
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/14015
___
Python tracker
<https://bugs.python.org/issu
Change by Jeroen Demeyer :
--
nosy: +yselivanov
___
Python tracker
<https://bugs.python.org/issue37249>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Jeroen Demeyer :
The function _PyObject_GetMethod is internal and private, but it should still
be declared properly. Currently, it is "manually" declared in two .c files
where it's used.
--
components: Interpreter Core
messages: 345336
nosy: jd
Jeroen Demeyer added the comment:
Note that this idea has been generalized by PEP 590: any type can support this
optimization by setting the Py_TPFLAGS_METHOD_DESCRIPTOR flag.
--
nosy: +jdemeyer
___
Python tracker
<https://bugs.python.
Jeroen Demeyer added the comment:
I think that the PyCode_New() compatibility problem and tp_print are
sufficiently closely related that they can be discussed together.
In any case, I agree that it makes little sense to fix just one
Jeroen Demeyer added the comment:
> SWIG creates the files correctly in the build_ext command
One could argue that running SWIG should be an entirely different step, not
part of build_ext.
I'm afraid that your idea of swapping build_ext and build_py will be rejected
because it ha
Jeroen Demeyer added the comment:
PR 14009 deals with tp_print
--
___
Python tracker
<https://bugs.python.org/issue37221>
___
___
Python-bugs-list mailin
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +13873
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/14009
___
Python tracker
<https://bugs.python.org/issu
Jeroen Demeyer added the comment:
Technically, tp_print was replaced by tp_vectorcall_offset.
But that doesn't answer the question how we should deal with tp_print backwards
compatibility. Cython does
FooType.tp_print = 0;
With this in mind, simply replacing tp_pri
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +13841
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/13974
___
Python tracker
<https://bugs.python.org/issu
New submission from Jeroen Demeyer :
The PEP 590 implementation for type "method" caused a minor regression: instead
of using _PyObject_Call_Prepend(), method_vectorcall manually allocates and
fills a newly allocated vector. This does NOT use the _PY_FASTCALL_SMALL_STACK
optimiz
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +13840
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/13973
___
Python tracker
<https://bugs.python.org/issu
New submission from Jeroen Demeyer :
Change call_method() and related functions in Objects/typeobject.c to allow
profiting from the PY_VECTORCALL_ARGUMENTS_OFFSET optimization: instead of
passing "self" as separate argument, put it inside the args vector.
--
components: I
Change by Jeroen Demeyer :
--
pull_requests: +13839
pull_request: https://github.com/python/cpython/pull/13972
___
Python tracker
<https://bugs.python.org/issue37
Jeroen Demeyer added the comment:
> Take into account that doing such rename will break again the projects that
> have adapted already (primarily only Cython).
+1. You already broke backwards compatibility once in beta1, no need to do it
again in beta2.
--
nosy: +jd
Jeroen Demeyer added the comment:
> Some of the problems brought up here (which sibling or subclass, and which
> parameter’s MRO) also came up a few years ago in Issue 23674.
Indeed. I would actually say that these two issues are duplicates of each
Jeroen Demeyer added the comment:
And this last comment is precisely the kind of information which should be
explained in the super() docs.
--
___
Python tracker
<https://bugs.python.org/issue37
Jeroen Demeyer added the comment:
> What matters is the __mro__ attribute of the first argument. It matters
because that is how the MRO actually is searched.
I'm sorry to say that you're wrong here. super() looks at the MRO of the type
of the object (the second argument) (*).
Jeroen Demeyer added the comment:
> It's well within our rights to ignore this: since 3.6 we require intermingled
> declarations.
It's not clear from PEP 7 if we require intermingled declarations only when
compiling CPython itself, or also for external packages that include
Jeroen Demeyer added the comment:
Should we revert these inline functions back to macros?
--
nosy: +jdemeyer
___
Python tracker
<https://bugs.python.org/issue37
Jeroen Demeyer added the comment:
> I propose to move the new *private* declarations to the internal C API.
Some of those functions (in particular _PyObject_Vectorcall) are expected to
become public in 3.9. They are only private for now since the API is
provisional.
--
n
101 - 200 of 588 matches
Mail list logo
