<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 29.03.2016 11:09, Paul Moore wrote:<br>
<blockquote
cite="mid:CACac1F_mkeSy46BwZGyLtBV6VGHXgmQkH_n2Neut6cE6TFJZeQ@mail.gmail.com"
type="cite">
<pre wrap="">On 29 March 2016 at 09:44, Sven R. Kunze <a class="moz-txt-link-rfc2396E" href="mailto:srkunze@mail.de"><srkunze@mail.de></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">
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?)</pre>
</blockquote>
<br>
Age is no indicator for "deserving".<br>
<br>
<br>
Because you are asking specifically for regexes, I might be able to
give an explanation.<br>
<br>
Regular expressions have, let's say, the tendency to grow. It's more
or less code, so they grow naturally.<br>
Readability, however, diminishes extremely fast with regexes when
compared to regular code.<br>
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.<br>
<br>
In short, we have far less usage of regular expressions than we see
for paths (from what I can see).<br>
<br>
If this speaks _for_ paths, I cannot say. But waiting 20 years for
this to happen might be a bit long.<br>
<br>
<br>
And hey, I wouldn't mind a builtin type for regular expressions
either if this makes things considerably easier. :)<br>
<br>
<blockquote
cite="mid:CACac1F_mkeSy46BwZGyLtBV6VGHXgmQkH_n2Neut6cE6TFJZeQ@mail.gmail.com"
type="cite">
<pre wrap="">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).
</pre>
<blockquote type="cite">
<pre wrap="">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 <a class="moz-txt-link-rfc2396E" href="http://domain.xyz/">"http://domain.xyz/"</a> 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
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<br>
Are you addressing me? The way you quoted makes it seem as if I had
written those lines. This is not true.<br>
<br>
<br>
Btw. I totally agree with the experience-proven way: module ->
stdlib module -> syntax.<br>
Btw2. we already have design experience in this field: requests +
<meta http-equiv="content-type" content="text/html; charset=utf-8">
URLObject. Not sure if you've ever used them, but they are amazing
(mainly they work and don't get into your way).<br>
<br>
<br>
Best,<br>
Sven<br>
</body>
</html>