Move pathlib implementation out of __init__.py

[barneygale]

Use the __init__.py file only for imports that define the API, following the example of asyncio.

See https://discuss.python.org/t/make-pathlib-extensible/3428/172

[barneygale]

@eryksun you mentioned renaming _abc.py to _pathlib_abc.py on the forum. Do you mean something like this?

Lib/pathlib.py
Lib/_pathlib_abc.py
Lib/_pathlib_glob.py
Lib/_pathlib_local.py

... because that would speed up the import of pathlib._glob from the glob module I think.

[eryksun]

Great if that really helps with performance. My issue was more trivial. I like to have easily recognizable names on tabs in my IDE. "_pathlib_abc.py" is a name that I can recognize in an instant without having to hover or use the document viewer.

[barneygale]

Hm. If I thumb through the standard library, there are quite a few submodules with generic basenames: asyncio.log, ctypes.util, email.errors, re._constants etc. I don't really mind either way, but it seems more consistent with the rest of Lib/ to consider the entire package path as the name. Can you configure your IDE to do that perhaps?

[eryksun]

No, not on tabs, and I wouldn't want qualified names on tabs. That's what the tree view of the documents viewer is for if I really need it. I know the standard library doesn't generally use easily recognizable module names in packages. That's why I qualified the asyncio example for what I personally prefer, and only for generic private names. Some names are easy for me to remember in context, such as "pool.py" in multiprocessing. It's just generic private names such as "_constants.py" that I wish had better names, since they aren't meant to be used in the public API anyway. But really almost anything is better than staring at a bunch of tabs labeled "__init__.py".

[barneygale]

Well, the __init__.py problem is improved at least. I'm not sure about adding a pathlib_ prefix to the other module names - I suspect other folks might find it overly repetitive and out of line with the rest of the stdlib. I hope you'll eventually forgive me if I merge this as-is. I'm open to renaming the modules in future if it becomes more obviously the correct thing to do.