> On Sep 11, 2016, at 1:37 AM, Victor Stinner <victor.stin...@gmail.com> wrote: > > For Python 3.7, I propose that we move all these private functions in > separated header files, maybe Include/private/ or Include/core/, and > not export them as part of the "regular API". > > The risk is that too many C extensions rely on all these tiny > "private" functions. Maybe for performance. I don't know. > > What do you think?
I think the risk is limited and inconsequential. We already document what is public, have specifically set aside a "limited" api, and the leading underscore private naming convention is both well established and well-understood. Even with pure python code, we make the claim that Python is a consenting adults language and that mostly works out just fine. The downside of the proposal is code churn and an increased maintenance burden. Having more include files to search through doesn't make it easier to learn the C code or to maintain it. Over time, the C code has gotten harder to read with cascades of macros and from breaking single concept files into multiple inter-dependent files. Raymond _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
