On Fri, 25 Mar 2016 at 16:50 Greg Ewing
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.