[Python-ideas] Making Path() a built in.

[Chris Barker - NOAA Federal]

>>> 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