BLD: consolidate remaining extensions by jreback · Pull Request #15537 · pandas-dev/pandas (original) (raw)

is there a specific reason libwindow is in core and not libs?

so from a code organization perspective. directly attributable libs make sense to be right next to there respective libs. general libs like lib, algos are centrally located. I did consider window to be with this. But from a dev point of view, editing window.py and then window.pyx right next to each is powerful. It moves the code together.

Similarly for json, sas, and the parser. They are self-contained. Its a tradeoff between dev flexibility and privacy really. I think the lib* naming really helps to differentiate this though and pretty much solves both problems.

the same as I commented in the other PR, IMO we should think about whether we need to recommend users to import from pandas.libs directly (the deprecation warnings now do that).

I could do this as pandas._libs as I indicated above. But in reality having underscores all over the place is simply distracting from a dev point of view (and ugly). So could do that, or put a README.

Regarding the indication of 'privateness', something like pandas.tools.libhash looks more public compared to pandas._hash to me (it's not because it is not top-level anymore, that it is not public. We have public non-top-level API). So if we regard that as non-public, I find that not an improvement (that aspect).

see comment above. I mean ALL of pandas code is 'public', but that's the point of having pandas.api in the first place anyhow. Sure any code can be used (even _ leading). But I think we need a warning about expectations generally. lib* should never be regarded as public.
I am personally in favour of using more underscores, making it very clear that something is private stuff.