On Sat, 26 Mar 2016 at 16:23 Koos Zevenhoven email@example.com wrote:
On Sat, Mar 26, 2016 at 9:10 PM, Brett Cannon firstname.lastname@example.org wrote:
On Fri, 25 Mar 2016 at 16:50 Greg Ewing email@example.com 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?
The trick is whether that import statement will work when you call it. Import is currently the only bit of syntax that relies on Python code in CPython to work and making that happen took a lot of work. If you add in this concept of p-strings then suddenly we have two pieces of syntax that require Python code to work and on top of it p-strings would depend on import but also that we would then have to make sure to not have import depend on p-strings. And on top of it we would have to freeze pathlib and all of its dependencies which may or may not be preferable.
My point is that it's not straight-forward and this proposal will have to consider some technical difficulties involved with it if it happens to go forward.
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.