On Wed, Mar 30, 2016 at 4:20 AM, Paul Moore <p.f.moore@gmail.com> wrote:
On 30 March 2016 at 09:45, Sven R. Kunze <srkunze@mail.de> wrote:
> On 29.03.2016 23:57, Paul Moore wrote:
>> On 29 March 2016 at 22:00, Sven R. Kunze <srkunze@mail.de> wrote:
>>> However, something that I cannot leave uncommented is "suboptimal
>>> representation for paths". What would your optimal representation for
>>> paths
>>> look like? I cannot believe that the current representation is so bad and
>>> has been for so long and nobody, really nobody, has anything done about
>>> it.
>> Well, pathlib.Path :-)
>> The point here is that C's char* representation is a serialisation of
>> a path object, just like 123 is a serialisation of an integer object.
>> We don't object to having to convert user input to a string if we need
>> to, why object to having to convert it to a Path if appropriate?
> I think there is a misunderstanding here. Let me quote myself:
> '''I think most "practicality beats purity" folks don't want that either.
> They are just bloody lazy. They actually want the benefits of both, the pure
> datastructure with its convenience methods and the dirty str-like thing with
> its convenience methods.'''
> The desire is not "str vs. Path"; its "Path + str". (at least from what I
> can tell)

I understand all that. I thought you were referring to Brett's comment
that C's "char *" format was "suboptimal" and asking what would be an
optimal representation (you said "your optimal representation",
meaning Brett's, so only he can answer to that but I took the question
more generally as what would be *an* optimal representation). My reply
was intended to say that I view something like pathlib.Path as

Really, these are actual graph paths sequences


* When you have to abspath, normpath, check for '../.../../.$var./..',
  you have to parse it by splitting on /, anyway,
  which indicates that a list/tuple would be more optimal
  in some use cases.

I don't personally see "working like a string" as being optimal,
precisely because it mixes the "structured object" level with the
"serialised representation" level. That's something Brett's article
clarified for me, so I suspect he'd have the same view.


To e.g. rsync, this is a different thing:


I doubt the people arguing for Path being a subclass of string would
be swayed by an argument like the above, though, as they would view it
as "purity over practicality". Personally, I find that careful
separation of concerns is a practicality benefit, in terms of
maintainability and clarity of code - a lesson I learned from having
to do far too many bytes/unicode migrations where separating out the
concepts was a vital step.

Practically, because path.py subclasses
unicode in python2 and str in python 3,
path.py should work with all existing standard library methods:

Anyway, this is pretty off topic, so I'll leave it there.
Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/