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

[Sven R. Kunze]

On 29.03.2016 11:09, Paul Moore wrote:
> 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?)

Age is no indicator for "deserving".


Because you are asking specifically for regexes, I might be able to give 
an explanation.

Regular expressions have, let's say, the tendency to grow. It's more or 
less code, so they grow naturally.
Readability, however, diminishes extremely fast with regexes when 
compared to regular code.
So, speaking from experience (and the moaning and groaning of the fellow 
team members), they might have been a good idea back then, nowadays we 
see they disadvantages more clearly.

In short, we have far less usage of regular expressions than we see for 
paths (from what I can see).

If this speaks _for_ paths, I cannot say. But waiting 20 years for this 
to happen might be a bit long.


And hey, I wouldn't mind a builtin type for regular expressions either 
if this makes things considerably easier. :)

> 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.

Are you addressing me? The way you quoted makes it seem as if I had 
written those lines. This is not true.


Btw. I totally agree with the experience-proven way: module -> stdlib 
module -> syntax.
Btw2. we already have design experience in this field: requests + 
URLObject. Not sure if you've ever used them, but they are amazing 
(mainly they work and don't get into your way).


Best,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160329/b212443b/attachment-0001.html>