On Tue., 24 Sep. 2019, 10:29 am Nathaniel Smith, <n...@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. >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/
