Upon further consideration and reading your response, I'm starting to think that the proposal to perform a mass renaming across stdlib might have been a bit too drastic, even if it was done over a longer period of time. Thanks for the detailed explanation of the costs, that significantly improved my understanding of the situation.
My primary motivation was to provide more explicit declaration of public vs private, not only for the purpose of shifting the responsibility to the authors, but also to shift the liability of using private members to the user. >From my perspective, if the communication is 100% clear that a particular >function is not public, the developers are able to make changes to it more >easily without being as concerned about the impact it will have on users. >Nothing prevents the users from using it anyways, but if a change that occurs >to a private function breaks their functionality, it's completely on them. >With the current system, users can potentially make the argument that they >weren't certain that it the function or module in question was private. Being >concerned about breaking the functionality for users on non-public functions >seems to entirely defeat the purpose of them. I also dislike the idea of adding the underscores or dealing with it on a case-by-case basis, due to the inconsistency it would provide across stdlib. In some cases the inconsistency might be necessary, but I'd rather avoid it if possible. Also, is the rule "unless explicitly documented public, all imports are private even if not prefixed with an underscore" officially stated anywhere, or is it mostly implied? Personally, I think that it should be explicitly stated in a public manner if it's the methodology being followed. A solid alternative proposal would also be Barry's public decorator proposal: https://public.readthedocs.io/en/latest/. I remember him saying that it was largely rejected by the community when it was proposed, but I'm not certain as to why. It would be far easier to implement something like this than it would be to rename all of the non-public functions. _______________________________________________ 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/OA7KTZFYJKKNGLX6GRGNMUGBZ34MDMWC/
