On Sat, Mar 26, 2016 at 9:10 PM, Brett Cannon email@example.com wrote:
On Fri, 25 Mar 2016 at 16:50 Greg Ewing firstname.lastname@example.org wrote:
On 24.03.2016 22:06, Koos Zevenhoven wrote:
Or even better, that you could do p"filename.txt", which would give
Path string object.
That would tie Path objects deeply into the parser and compiler, which I'm not sure is a good idea.
I'll go one step further than Greg and say that it's not a good idea. To make something like this work you have two options. One is you do what importlib does and very carefully construct it to only rely on built-in modules (and if you look at https://hg.python.org/cpython/file/default/Lib/pathlib.py you will notice that is no where near true ATM). Two, is Python gets a two-tier syntax system for before and after pathlib is imported and available. That would mean that all the dependencies of pathlib would need to not use this syntax until it's bootstrapped in. If you notice, both solutions are extremely painful to implement and radiate well past the code in pathilb.py and would potentially become hard to maintain.
As I understand it, this could be implemented by making the compiler essentially turn p"/path/to/whatever" into something like _make_path("/path/to/whatever"), where _make_path would be builtin and do something like this.
def _make_path(str_path): import pathlib return pathlib.Path(str_path)
Unless of course Path could be modified to import its dependencies on demand and put in builtins. Am I missing something crucial?
I also want to mention two things. One, pathlib.path is a thing now and something most people are probably not aware of as an alternative to doing `str(path)`: https://docs.python.org/3/library/pathlib.html#pathlib.PurePath.path .
I assume you meant to type pathlib.Path.path, so that Path("...").path == str(Path("...")). That's a good start, and I'm looking forward to Serhiy's patch for making the stdlib accept Paths. But if Path will not subclass str, we also need new stdlib functions that *return* Paths.