Re: [Python-Dev] General concerns about C API changes

2018-11-23 Thread Victor Stinner
Le dim. 18 nov. 2018 à 17:54, Stefan Behnel a écrit : > It's also slower to compile, given that function inlining happens at a much > later point in the compiler pipeline than macro expansion. The C compiler > won't even get to see macros in fact, whereas whether to inline a function > or not is

Re: [Python-Dev] General concerns about C API changes

2018-11-19 Thread Antoine Pitrou
On Sun, 18 Nov 2018 13:53:54 -0800 Nathaniel Smith wrote: > On Sun, Nov 18, 2018 at 8:52 AM Stefan Behnel wrote: > > > > Gregory P. Smith schrieb am 15.11.18 um 01:03: > > > From my point of view: A static inline function is a much nicer modern > > > code > > > style than a C preprocessor

Re: [Python-Dev] General concerns about C API changes

2018-11-18 Thread Nathaniel Smith
On Sun, Nov 18, 2018 at 8:52 AM Stefan Behnel wrote: > > Gregory P. Smith schrieb am 15.11.18 um 01:03: > > From my point of view: A static inline function is a much nicer modern code > > style than a C preprocessor macro. > > It's also slower to compile, given that function inlining happens at a

Re: [Python-Dev] General concerns about C API changes

2018-11-18 Thread Stefan Behnel
Gregory P. Smith schrieb am 15.11.18 um 01:03: > From my point of view: A static inline function is a much nicer modern code > style than a C preprocessor macro. It's also slower to compile, given that function inlining happens at a much later point in the compiler pipeline than macro expansion.

Re: [Python-Dev] General concerns about C API changes

2018-11-14 Thread Victor Stinner
Le jeu. 15 nov. 2018 à 01:06, Gregory P. Smith a écrit : > I expect the largest visible impact may be that a profiler may now attribute > CPU cycles takes by these code snippets to the function from the .h file > rather than directly to the functions the macro expanded in in the past due > to

Re: [Python-Dev] General concerns about C API changes

2018-11-14 Thread Gregory P. Smith
On Tue, Nov 13, 2018 at 7:06 PM Raymond Hettinger < raymond.hettin...@gmail.com> wrote: > Overall, I support the efforts to improve the C API, but over the last few > weeks have become worried. I don't want to hold up progress with fear, > uncertainty, and doubt. Yet, I would like to be more

Re: [Python-Dev] General concerns about C API changes

2018-11-14 Thread Jeroen Demeyer
On 2018-11-14 04:06, Raymond Hettinger wrote: With cross module function calls, I'm less confident about what is happening If the functions are "static inline" (as opposed to plain "inline"), those aren't really cross-module function calls. Because the functions are "static" and defined in a

Re: [Python-Dev] General concerns about C API changes

2018-11-14 Thread Victor Stinner
> First, I attempted for "force inlining" (ex: > __attribute__((always_inline)) for GCC/Clang), but it has been decided > to not do that. Please read the discussion on the issue for the > rationale. > > https://bugs.python.org/issue35059 It has been decided to use "static inline" syntax since

Re: [Python-Dev] General concerns about C API changes

2018-11-14 Thread Victor Stinner
Hi, I made many different kinds of changes to the C API last weeks. None of them should impact the backward compatibility. If it's the case, the changes causing the backward compatibility should be reverted. The most controversial changes are the conversion of macros to static inline functions,

Re: [Python-Dev] General concerns about C API changes

2018-11-13 Thread Nathaniel Smith
To me, the "new C API" discussion and the "converting macros into inline functions" discussions are very different, almost unrelated. There are always lots of small C API changes happening, and AFAIK the macros->inline changes fall into that category. It sounds like you want to discuss whether