<p dir="ltr"><br>
On Apr 6, 2016 1:26 AM, "Chris Angelico" <<a href="mailto:rosuav@gmail.com">rosuav@gmail.com</a>> wrote:<br>
><br>
> On Wed, Apr 6, 2016 at 3:37 PM, Stephen J. Turnbull <<a href="mailto:stephen@xemacs.org">stephen@xemacs.org</a>> wrote:<br>
> > Chris Angelico writes:<br>
> ><br>
> >  > Outside of deliberate tests, we don't create files on our disks<br>
> >  > whose names are strings of random bytes;<br>
> ><br>
> > Wishful thinking.  First, names made of control characters have often<br>
> > been deliberately used by miscreants to conceal their warez.  Second,<br>
> > in some systems it's all too easy to create paths with components in<br>
> > different locales (the place I've seen it most frequently is in NFS<br>
> > mounts).  I think that's much less true today, but perhaps that's only<br>
> > because my employer figured out that it was much less pain if system<br>
> > paths were pure ASCII so that it mostly didn't matter what encoding<br>
> > users chose for their subtrees.<br>
><br>
> Control characters are still characters, though. You can take a<br>
> bytestring consisting of byte values less than 32, decode it as UTF-8,<br>
> and have a series of codepoints to work with.<br>
><br>
> If your employer has "solved" the problem by restricting system paths<br>
> to ASCII, that's a fine solution for a single system with a single<br>
> ASCII-compatible encoding; a better solution is to mandate UTF-8 as<br>
> the file system encoding, as that's what most people are expecting<br>
> anyway.<br>
><br>
> > It remains important to be able to handle nearly arbitrary bytestrings<br>
> > in file names as far as I can see.  Please note that 100 million<br>
> > Japanese and 1 billion Chinese by and large still prefer their<br>
> > homegrown encodings (plural!!) to Unicode, while many systems are now<br>
> > defaulting filenames to UTF-8.  There's plenty of room remaining for<br>
> > copying bytestrings to arguments of open and friends.<br>
><br>
> Why exactly do they prefer these other encodings? Are they<br>
> representing characters that Unicode doesn't contain? If so, we have a<br>
> fundamental problem (no Python program is going to be able to cope<br>
> with these, without a third party library or some stupid mess of local<br>
> code); if not, you can always represent it as Unicode and encode it as<br>
> UTF-8 when it reaches the file system. Re-encoding is something that's<br>
> easy when you treat something as text, and impossible when you treat<br>
> it as bytes.<br>
><br>
> So far, you're still actually agreeing with me: paths are *text*, but<br>
> sometimes we don't know the encoding (and that's a problem to be<br>
> solved).</p>
<p dir="ltr">re: bytestring, unicode, encodings after e.g. os.path.split / Path.split:</p>
<p dir="ltr">from "[Python-ideas] Type hints for text/binary data in Python 2+3 code"</p>
<p dir="ltr"><a href="https://mail.python.org/pipermail/python-ideas/2016-March/038869.html">https://mail.python.org/pipermail/python-ideas/2016-March/038869.html</a></p>
<p dir="ltr">>> would/will it be possible to<br>
use Typing.Text as a base class for even-more abstract string types</p>
<p dir="ltr"><a href="https://mail.python.org/pipermail/python-ideas/2016-March/039016.html">https://mail.python.org/pipermail/python-ideas/2016-March/039016.html</a></p>
<p dir="ltr">>> * Text.encoding<br>
>> * Text.lang (urn:ietf:rfc:3066)<br>
... forgot to CC:<br>
 >> * <a href="https://tools.ietf.org/html/rfc5646">https://tools.ietf.org/html/rfc5646</a><br>
  "Tags for Identifying Languages"<br>
  urn:ietf:rfc:5646</p>
<p dir="ltr">is this (Path) a narrower case of string types (#strypes), because after transformations we want to preserve string metadata like e.g encoding?</p>
<p dir="ltr">I'd vote for <br>
* adding DirEntry.__path__ as a proxy to DirEntry.path<br>
* standardizing on __path__ (over .path)<br>
  * because this operation *is* fundamentally similar to e.g. __str__<br>
    * operator.path pathify, pathifize<br></p>
<p dir="ltr">><br>
> ChrisA<br>
> _______________________________________________<br>
> Python-Dev mailing list<br>
> <a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/python-dev">https://mail.python.org/mailman/listinfo/python-dev</a><br>
> Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com">https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com</a><br>
</p>