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

[Paul Moore]

On 29 March 2016 at 09:44, Sven R. Kunze <srkunze at mail.de> wrote:
>
> I don't think we (as the Python community) can allow ourselves to stand
> still. We need to have tools that are simple and available. If YAML is the
> new standard for everything, Python should move. If $ before variable names
> are the new standard (I hope they never will again), Python should move.
>
> I understand that there are preservers who don't want anything to change.
> So, compromises will be necessary.

I agree 100% that Python should not stand still. However, every
addition to the core language involves a backward compatibility cost
that must be very carefully weighed. If we built XML into the language
back when that was the standard, then we'd now be looking at adding
YAML, but we wouldn't be able to remove XML without significant pain.

So a conservative approach *to core language syntax* is entirely reasonable.

Having said that, Python has a very good means of adding new
*functionality* in the form of modules, and an very good path for
gradually standardising modules in the form of personal library ->
PyPI package -> stdlib package.

It seems to me that this route is appropriate here. At the moment,
pathlib has been included as a stdlib library, based on the experience
gained from the various PyPI packages developed beforehand. There
still seem to be some reservations in the community over the adoption
of pathlib, and the first thing we need to do is to resolve those,
before we even think about promoting the library to syntax (after all,
regular expressions have been round *forever*, and still aren't built
in syntax, in spite of the precedents in Perl, Javascript, and other
languages - why are Path objects so much more deserving of a fast
track?)

I'm much more in favour of discussions on how to address the perceived
shortcomings of pathlib over alternatives like path.py and pylib's
path object. If it's all about subclassing str, then let's by all
means reopen that debate - making Path a str subclass is something
that could be done as a stdlib change if the decision made in the
original PEP was agreed to be flawed (I'm not sure it was, personally,
but I'm open to a discussion on that, as the need to convert to and
from strings certainly is a nuisance).

> To be honest, I do think it feels like URL:s are becoming (or have become)
> just as important as paths, and that pathlib.Path should in the future work
> with URLs just like it now works with windows and posix paths. The
> difference between "http://domain.xyz/" and "C:\\" is not huge. I also think
> there should be a Python type (stdlib or builtin), which handles JSON
> objects nicer than dicts do and has its own literal

So again, if you have personal code you find cleaner and more usable
for this job, publish it on PyPI, publicise it and gain support for
it, and then propose it for stdlib inclusion. This also has the
advantage of being useful for Python 3.4/3.5 users (and you can even
support Python 2.7 if you wish).

I've no idea how we would ensure that a built in syntax for URLs was
correctly designed without having got design experience with the
feature as a library module.

Paul