<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 30, 2016 at 4:20 AM, Paul Moore <span dir="ltr"><<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 30 March 2016 at 09:45, Sven R. Kunze <<a href="mailto:srkunze@mail.de">srkunze@mail.de</a>> wrote:<br>
> On 29.03.2016 23:57, Paul Moore wrote:<br>
>><br>
>> On 29 March 2016 at 22:00, Sven R. Kunze <<a href="mailto:srkunze@mail.de">srkunze@mail.de</a>> wrote:<br>
>>><br>
>>> However, something that I cannot leave uncommented is "suboptimal<br>
>>> representation for paths". What would your optimal representation for<br>
>>> paths<br>
>>> look like? I cannot believe that the current representation is so bad and<br>
>>> has been for so long and nobody, really nobody, has anything done about<br>
>>> it.<br>
>><br>
>> Well, pathlib.Path :-)<br>
>><br>
>> The point here is that C's char* representation is a serialisation of<br>
>> a path object, just like 123 is a serialisation of an integer object.<br>
>> We don't object to having to convert user input to a string if we need<br>
>> to, why object to having to convert it to a Path if appropriate?<br>
><br>
><br>
> I think there is a misunderstanding here. Let me quote myself:<br>
><br>
> '''I think most "practicality beats purity" folks don't want that either.<br>
> They are just bloody lazy. They actually want the benefits of both, the pure<br>
> datastructure with its convenience methods and the dirty str-like thing with<br>
> its convenience methods.'''<br>
><br>
> The desire is not "str vs. Path"; its "Path + str". (at least from what I<br>
> can tell)<br>
<br>
</span>I understand all that. I thought you were referring to Brett's comment<br>
that C's "char *" format was "suboptimal" and asking what would be an<br>
optimal representation (you said "your optimal representation",<br>
meaning Brett's, so only he can answer to that but I took the question<br>
more generally as what would be *an* optimal representation). My reply<br>
was intended to say that I view something like pathlib.Path as<br>
optimal.<br></blockquote><div><br></div><div>Really, these are actual graph paths sequences</div><div><br></div><div>Because:</div><div><br></div><div>* When you have to abspath, normpath, check for '../.../../.$var./..',</div><div> you have to parse it by splitting on /, anyway,</div><div> which indicates that a list/tuple would be more optimal</div><div> in some use cases.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I don't personally see "working like a string" as being optimal,<br>
precisely because it mixes the "structured object" level with the<br>
"serialised representation" level. That's something Brett's article<br>
clarified for me, so I suspect he'd have the same view.<br></blockquote><div><br></div><div>"</div><div><br></div><div>To e.g. rsync, this is a different thing:</div><div><br></div><div> ./path/</div><div> ./path</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I doubt the people arguing for Path being a subclass of string would<br>
be swayed by an argument like the above, though, as they would view it<br>
as "purity over practicality". Personally, I find that careful<br>
separation of concerns is a practicality benefit, in terms of<br>
maintainability and clarity of code - a lesson I learned from having<br>
to do far too many bytes/unicode migrations where separating out the<br>
concepts was a vital step.<br></blockquote><div><br></div><div>Practically, because path.py subclasses</div><div>unicode in python2 and str in python 3,</div><div>path.py should work with all existing standard library methods:</div><div><a href="https://github.com/jaraco/path.py/blob/master/path.py">https://github.com/jaraco/path.py/blob/master/path.py</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Anyway, this is pretty off topic, so I'll leave it there.<br>
<span class=""><font color="#888888">Paul<br>
</font></span><div class=""><div class="h5">_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br>
</div></div></blockquote></div><br></div></div>