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 comfortable that we're
all aware of what is occurring and what are the potential benefits and r
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 inli
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, bu
> 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 it's
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
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 com
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 a
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. T
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
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 macr
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 a
11 matches
Mail list logo