...

Right, I'm pretty sure that right now Python doesn't have any way to share symbols between .c files without also exposing them in the C API.

On other C projects I've worked on, the public API is expressed in one set of header files, and internal APIs that need to be exposed across modules are described in a different set of internal header files, and developers who incorrectly use internal APIs by including the internal headers could see breakage when the internals change ... excuse my naïveté, as I haven't done much at Python's C level - does this discipline/approach not apply to CPython? Regards, Vinay Sajip

requires some newer tools like -fvisibility=hidden that work differently across different platforms, and so far no-one's done the work to sort out the details.

I've started looking at this, but quite apart from the specifics of applying -fvisibility=hidden, there are some things that aren't yet clear to me about the intent behind some of our symbol definitions. For example, the file Include/fileutils.h contains the definitions PyAPI_FUNC(wchar_t *) Py_DecodeLocale(const char *arg, size_t *size); and PyAPI_FUNC(int) _Py_DecodeLocaleEx(const char *arg, wchar_t **wstr, size_t *wlen, const char **reason, int current_locale, _Py_error_handler errors); However, only the first of these is documented, though the definition via PyAPI_FUNC implies that both are part of the public API. If this is the case, why aren't both documented? If _Py_DecodeLocaleEx is not part of the public API (and the leading underscore suggests so), should it be polluting the symbol space? The comment for PyAPI_FUNC is "Declares a public Python API function and return type". Is this really the case, or has PyAPI_FUNC been coopted to provide external linkage for use by Python-internal code in different compilation units? _Py_DecodeLocaleEx is called in Modules/_testcapimodule.c and also in Objects/unicodeobject.c. If we want to take steps to restrict symbol visibility, it will potentially affect all of the code base - so presumably, a PEP would be required, even though it's an implementation detail from the point of view of the language itself? Regards, Vinay Sajip

Nathaniel Smith wrote:

Windows already has working symbol visibility handling, and PyAPI_FUNC is what controls it. So adding symbol visibility handling to Linux/macOS is just about making all the platforms consistent. There might be some weird choices being made, but I don't think you need to sort all those out as part of this.

Well, _Py_DecodeLocaleEx is declared with PyAPI_FUNC, so would you expect it to be exposed on Windows? I haven't a Windows machine handy right now, but I would expect it not to be exposed, as it doesn't appear in PC/python3.def. I will check when I get a chance. Regards, Vinay Sajip

Le lun. 23 sept. 2019 à 21:36, Vinay Sajip via Python-Dev a écrit :

Nathaniel Smith wrote:

...

Windows already has working symbol visibility handling, and PyAPI_FUNC is what controls it. So adding symbol visibility handling to Linux/macOS is just about making all the platforms consistent. There might be some weird choices being made, but I don't think you need to sort all those out as part of this.

Well, _Py_DecodeLocaleEx is declared with PyAPI_FUNC, so would you expect it to be exposed on Windows?

_Py_DecodeLocaleEx() should not be used outside Python. It's really a low-level function which should not be used directly. Its definition should be moved to the internal API and it should use extern rather than PyAPI_FUNC(). It's a private API so we can make it internal. Victor -- Night gathers, and now my watch begins. It shall not end until my death.

On 2019-09-23 21:22, Vinay Sajip via Python-Dev 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?

It's not really a question of which ones should be made private, but of which ones should be remain public. If it's mentioned in the docs, then it's public, otherwise it should be private. How easy would it be to search the sources and the docs for the ones that are currently public but not documented?

On Mon, Sep 23, 2019 at 1:30 PM Vinay Sajip via Python-Dev 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. -n -- Nathaniel J. Smith -- https://vorpus.org

On Tue., 24 Sep. 2019, 10:29 am Nathaniel Smith, wrote:

On Mon, Sep 23, 2019 at 1:30 PM Vinay Sajip via Python-Dev 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.

Thanks for the pointer. According to that information, everything in Include/fileutils.h should be the portable public C API. But there are definitions in there which start with _Py - and the information relating to Include/cpython/*.h suggests that API prefixed with _Py is conventionally private. Is there a reason why (for example) _Py_DecodeLocaleEx appears in Include/*.h with a prefix conventionally suggesting it's private, and which is backed up by the fact that it's not mentioned in the C API documentation? If it's just there for the moment because no-one got around to moving it to Include/cpython/*.h, it would be useful to know that. I'm not trying to nit-pick here - if we're going to apply visibility rules, then things like this need to be absolutely clear. Just for info, I tried configuring and compiling with -fvisibility=hidden and declared default visibility on PyAPI_FUNC, PyAPI_DATA and PyMODINIT_FUNC, as well as one or two other declarations. The resulting build passes all tests run locally, except test_tools (which is currently also failing for me on master). I haven't yet pushed these changes to my public CPython fork, as it's still work in progress - which is why I'm asking these questions. Regards, Vinay Sajip

Moving some of the especially common identifier references into the interpreter state struct may make sense. Adding more process globals wouldn't be desirable though, as they're one of the more common ways of breaking encapsulation between subinterpreters (hence Eric's efforts to eliminate as many of them as he reasonably can).

Well, another way of breaking encapsulation is by having ad hoc statics (as opposed to globals) which should really be in the interpreter state - it prevents compartmentalizing the GIL into per-subinterpreter GILs, for example. That's my motivation for looking at this area - I spent a bit of time working with Eric at the recent core dev sprint, and wanted to explore the problems in this area. Regards, Vinay