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

[Steven D'Aprano]

On Tue, Jun 05, 2018 at 11:23:55PM -0700, Chris Barker wrote:
> On Tue, Jun 5, 2018 at 4:42 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> 
> > This is a quick and dirty survey of my code:
[snip grepping]
> I"m not saying I agree with the OP, but this is not a fair comparison at
> all -- Path is pretty new, and even newer is it functional with most of teh
> stdlib.
> 
> I do a lot of path manipulations in my code, but hardly ever use Path --
> nly brand new code uses it.
> 
> so I think you'd need to grep for os.path (and probably shutil, too) to get
> a meaningful answer.

Why? The OP isn't asking for os.path and shutil to be builtins.

The OP's statement wasn't "file manipulations of any sort, using any 
technique including Path, os.path, shutil and string processing, is more 
common than enumerate etc". (For *my own code* I'd disagree with that 
claim too, but other's experience may vary.) It was specifically that 
Path was more common than enumerate.

Maybe it is for him, but that isn't a universal fact.


> But key here is that there is no consensus that Path is the new "obvious
> way to do it", and adding it to builtins would be essentially making that
> statement.

Indeed.

I think there are at least three hurdles to overcome before Path could 
become a builtin:

- concensus, or at least a BDFL ruling, that path manipulation is
  important enough to be a builtin.

  (If we're voting, I'd rather have sqrt as a builtin. But maybe that's
  just me :-)

- agreement that Path is the One Obvious Way that should be officially
  promoted over os.path;

- and determination that making Path a builtin would not cause an
  excessive or onerous burden on the core developers;

- or a serious regression in interpreter startup.

(pathlib is a reasonably big library, over 1000 LOC, which relies on 
over a dozen other modules.)


-- 
Steve