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