[Python-ideas] Working with Path objects: p-strings?

[Brett Cannon]

On Sat, 26 Mar 2016 at 16:23 Koos Zevenhoven <k7hoven at gmail.com> wrote:

> On Sat, Mar 26, 2016 at 9:10 PM, Brett Cannon <brett at python.org> wrote:
>
>>
>>
>> On Fri, 25 Mar 2016 at 16:50 Greg Ewing <greg.ewing at canterbury.ac.nz>
>> wrote:
>>
>>> >>>On 24.03.2016 22:06, Koos Zevenhoven wrote:
>>> >>>
>>> >>>Or even better, that you could do p"filename.txt", which would give
>>> you a
>>> >>>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.

-Brett


>
>
>>
>> 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.
>
>  - Koos
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160327/da874786/attachment.html>