[prev in list] [next in list] [prev in thread] [next in thread]
List: python-dev
Subject: [Python-Dev] Re: static variables in CPython - duplicated _Py_IDENTIFIERs?
From: Nick Coghlan <ncoghlan () gmail ! com>
Date: 2019-09-28 23:17:59
Message-ID: CADiSq7ezsayw9jGuD4V0Q5m=nVUfPxVYW58aAFST=WThC_CX9w () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Tue., 24 Sep. 2019, 10:29 am Nathaniel Smith, <njs@pobox.com> wrote:
> On Mon, Sep 23, 2019 at 1:30 PM Vinay Sajip via Python-Dev
> <python-dev@python.org> wrote:
> >
> > OK - but that's just one I picked at random. There are others like it -
> what would be the process for deciding which ones need to be made private
> and moved? Should an issue be raised to track this?
>
> There are really two issues here:
>
> - hiding the symbols that *aren't* marked PyAPI_*, consistently across
> platforms.
> - finding symbols that are currently marked PyAPI_*, but shouldn't be.
>
> The first one is a pretty straightforward technical improvement. The
> second one is a longer-term project that could easily get bogged down
> in complex judgement calls. So let's worry about them separately. Even
> if there are too many symbols marked PyAPI_*, we can still get started
> on hiding all the symbols that we *know* should be hidden.
>
One of the other things to keep in mind is that a lot of new symbol exports
are created by copying an existing one, rather than by going & reading the
C API documentation on exporting symbols correctly.
Historically, though, it wasn't especially obvious from the header files
themselves that "exported for internal linkage" and "exported as part of
the public C API" should be written differently, so it was easy to use the
wrong style, and patch reviewers wouldn't necessarily notice.
With the structural split now in place, the creep of incorrectly published
symbols should be contained, and the public header files can start being
reviewed for cases like this one.
Cheers,
Nick.
>
[Attachment #5 (text/html)]
<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On \
Tue., 24 Sep. 2019, 10:29 am Nathaniel Smith, <<a \
href="mailto:njs@pobox.com">njs@pobox.com</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">On Mon, Sep 23, 2019 at 1:30 PM Vinay Sajip via \
Python-Dev<br> <<a href="mailto:python-dev@python.org" target="_blank" \
rel="noreferrer">python-dev@python.org</a>> wrote:<br> ><br>
> OK - but that's just one I picked at random. There are others like it - what \
would be the process for deciding which ones need to be made private and moved? \
Should an issue be raised to track this?<br> <br>
There are really two issues here:<br>
<br>
- hiding the symbols that *aren't* marked PyAPI_*, consistently across<br>
platforms.<br>
- finding symbols that are currently marked PyAPI_*, but shouldn't be.<br>
<br>
The first one is a pretty straightforward technical improvement. The<br>
second one is a longer-term project that could easily get bogged down<br>
in complex judgement calls. So let's worry about them separately. Even<br>
if there are too many symbols marked PyAPI_*, we can still get started<br>
on hiding all the symbols that we *know* should be \
hidden.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">One of \
the other things to keep in mind is that a lot of new symbol exports are created by \
copying an existing one, rather than by going & reading the C API documentation \
on exporting symbols correctly.</div><div dir="auto"><br></div><div \
dir="auto">Historically, though, it wasn't especially obvious from the header \
files themselves that "exported for internal linkage" and "exported as \
part of the public C API" should be written differently, so it was easy to use \
the wrong style, and patch reviewers wouldn't necessarily notice.</div><div \
dir="auto"><br></div><div dir="auto">With the structural split now in place, the \
creep of incorrectly published symbols should be contained, and the public header \
files can start being reviewed for cases like this one.</div><div \
dir="auto"><br></div><div dir="auto">Cheers,</div><div dir="auto">Nick.</div><div \
dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div \
dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 \
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br> \
</blockquote></div></div></div>
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/7DW34MYR3DZKUXW76DMLB54V22PWMCVX/
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic