For the startup time, you could keep it around as builtin but save the import time until someone actually uses it.
That would mean creating a system of lazy imports, which is an entirely separate proposal.
It's that complicated ? I know it's not exactly properties on a class, but I thought there were other cases, even if I couldn't name one. Dont mind me, then.
It wouldn’t be THAT hard to wrote lazy-import code for pathlib. But there has been a lot of discussion lately about Python startup time. One approach is to create a lazy-import system that could be generally used to help startup time. So I expect that an expensive to import built in will not get added unless that problem is generically solved. And as for Steven’s other points: There has been a fair bit of discussion here and on Python-dev about pathlib. The fact is that it is still not ready to be a full featured replacement for os.path, etc. And a number of core devs aren’t all that interested in it becoming the “one obvious way”. So I think we are no where near it becoming a built in. But if you like it, you can help the efforts to make it even more useful, which would be good in itself, but is also the Path (pun intended) to making it the “one obvious way”. If it’s useful enough, people will use it, even if the have to import it. There was a recent thread about adding functionality to the Oath object that seems to have petered out— maybe contribute to that effort? One more point: A major step in making pathlib useful was adding the __path__ protocol, and then adding support for it in most (all) of the standard library. Another step would be to make any paths in the stdlib (such as __file__) Path objects (as suggested in this thread) but that would bring up the startup costs problem. I wonder if a Path-lite with the core functionality, but less startup cost, would be useful here? -CHB