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

[Brett Cannon]

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.


>
> Also, it would be stretching the string-prefix concept considerably.
> Currently, the prefixes just represent different ways of specifying
> a string -- the end result is still always an instance of str.
> In this proposal, it would be a different type of object with
> greatly different behaviour.
>

Yep, that too.


>
> Not sure whether I feel positively or negatively about this,
> so +0j.
>

I'm sure how I feel :) -1.

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 . And
two, wrapping path inputs in `pathlib.Path(path)` is a small price to pay
for a nicer API. As time passes it will be less and less of a thing as APIs
will start to come up that explicitly accept either, and then eventually
they will only accept pathlib. Plus if you do it at the edges of your own
API then you can do the conversion early and only get out the string as
necessary later on as needed (much like how you handle text/binary data
boundaries). I get the desire of succinctness as Python spoils us for that,
but much like __future__ statements it's really a small price to pay in the
grand scheme of things in order to migrate to a better API.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160326/db140009/attachment.html>