Description
In 2020 we made some progress on avoiding importing private functions/classes, enforced by validate_unwanted_patterns.private_import_across_module. Along the same lines (and frankly way more difficult), it would be Best Practice to avoid accessing private attributes/methods at runtime, e.g. in NDFrame.xs we call index._get_loc_level and ideally we would use a public MultiIndex method instead.
I imagine a code check could grep (many code checks actually do ast traversal) for "(?<!self)._"
The trouble with this idea is that privateness can be intended for either a) end users or b) intra-pandas isolation. So in the _get_loc_level example just making that method public would also make it public for users, which isn't the goal here. The same tradeoff applies to many EA methods that we don't really want end users using but that are very frequently called non-privately.
A few possible ways forward here
- Decide we don't care about this, continue with the status quo
- Decide we care about this in a subset of files/attributes/methods which we could potentially expand over time (as we do with many code checks)
- implement a 3-tier naming scheme for public, private, really-private