Fair enough. Pull request created:
https://github.com/python/cpython/pull/16347
Regards,
Vinay Sajip
___
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
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?
Regards,
Vinay Sajip
___
Python-Dev mailing list -- p
Ah - I checked, and it's there OK ... (head scratch)
Regards,
Vinay Sajip
___
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/
Mess
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
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
priva
> 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
> 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 eliminat
> > 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
> From my understanding, _Py_IDENTIFIER was designed for static usage.
> The overhead is quite low; keeping it as a private (static)
> module-level internal variable helps to decouple things.
I understand the importance of decoupling in general, but meanings of __name__,
__dict__ etc. aren't goin
I just ran an analysis of static variable definitions in CPython code, using
clang, on Ubuntu and Windows. The results should be available here:
https://cpython.red-dove.com/
As I understand it, _Py_IDENTIFIER instances are supposed to hold constant
strings that are used in Python - e.g. "__cla
10 matches
Mail list logo
