[Python-ideas] Making Path() a built in.
steve at pearwood.info
Wed Jun 6 02:53:32 EDT 2018
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:
> 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
> 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
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.)
More information about the Python-ideas