<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    On 27.03.2016 00:51, Koos Zevenhoven wrote:<br>
    <blockquote
cite="mid:CAMiohohB6xmDi9suUMo-AcE4Z=e2p-uZLspC31Nbmtz5f5MhiQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">On Sun, Mar 27, 2016 at 1:13 AM, Greg
            Ewing <span dir="ltr"><<a moz-do-not-send="true"
                href="mailto:greg.ewing@canterbury.ac.nz"
                target="_blank">greg.ewing@canterbury.ac.nz</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">[...]<br>
              This feels like a slippery slope to me. If we include<br>
              special syntax for pathnames, why shouldn't we have it<br>
              for dates and times? Regular expressions? URLs? JSON<br>
              data? SQL queries? XML data? Where do we draw the line?<span
                class=""><br>
              </span></blockquote>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Just because you want to draw a line does not necessarily mean, we
    want to draw one. ;)<br>
    <br>
    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.<br>
    <br>
    I understand that there are preservers who don't want anything to
    change. So, compromises will be necessary.<br>
    <br>
    <blockquote
cite="mid:CAMiohohB6xmDi9suUMo-AcE4Z=e2p-uZLspC31Nbmtz5f5MhiQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>OT: </div>
            <div><br>
            </div>
            <div>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 moz-do-not-send="true"
                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 </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    That even occurred to me after we talked about the p-string (mainly
    because I am working in this field, so I basically need both file
    paths and URIs).<br>
    <br>
    <br>
    I agree with the URI/IRI idea. It feels natural and sometimes it is
    necessary to extract specific parts from an URL according to RFC
    3986 or 3987. So, +1 from me.<br>
    <br>
    <br>
    Just for the record: "Path" might not be the most correct wording.
    There is a <a class="moz-txt-link-rfc2396E" href="file://">"file://"</a> scheme which identifies locally located files.
    So, paths are basically a subset of URLs speaking
    functionality-wise. Thus, a better/more generic name would be "URL",
    "URI", "Link" or the like in order to avoid confusing of later
    generations. However, I think I could live with Path.<br>
    <br>
    <br>
    Another thought: requesting URLs. Basically the same as
    p'/etc/hosts'.write_text(secret). It's really important to have a
    dead simple library which is able to work with URLs. So, if I could
    do:<br>
    <br>
    p'<a class="moz-txt-link-freetext" href="https://mysite.com/">https://mysite.com/</a>{page}'.get() <br>
    <br>
    that'll be awesome.<br>
    <br>
    Best,<br>
    Sven<br>
  </body>
</html>