Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PEP 670: Remove duplicated paragraph #2118

Merged
merged 1 commit into from
Oct 19, 2021
Merged

PEP 670: Remove duplicated paragraph #2118

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 9 additions & 17 deletions pep-0670.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -123,19 +123,6 @@ especially useful on LTO+PGO builds which heavily inlines code: see
``__declspec(noinline)`` with MSC.


Convert macros and static inline functions to regular functions
---------------------------------------------------------------

There are projects embedding Python or using Python which cannot use
macros and static inline functions. For example, projects using
programming languages other than C and C++. There are also projects
written in C which make the deliberate choice of only getting
``libpython`` symbols (functions and variables).

Converting macros and static inline functions to regular functions make
these functions accessible to these projects.


Specification
=============

Expand All @@ -158,12 +145,17 @@ The following macros should not be converted:
Convert static inline functions to regular functions
----------------------------------------------------

Converting static inline functions to regular functions give access to
these functions for projects which cannot use macros and static inline
functions.
There are projects embedding Python or using Python which cannot use
macros and static inline functions. For example, projects using
programming languages other than C and C++. There are also projects
written in C which make the deliberate choice of only getting
``libpython`` symbols (functions and variables).

Converting static inline functions to regular functions makes these
regular functions accessible to these projects.

The performance impact of such conversion should be measured with
benchmarks. If there is a significant slowdown, there should be a good
benchmarks. If there is a significant slowdown, there should be a good
reason to do the conversion. One reason can be hiding implementation
details.

Expand Down