[Python-ideas] Working with Path objects: p-strings?

[Paul Moore]

On 30 March 2016 at 09:45, Sven R. Kunze <srkunze at mail.de> wrote:
> On 29.03.2016 23:57, Paul Moore wrote:
>>
>> On 29 March 2016 at 22:00, Sven R. Kunze <srkunze at 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
optimal.

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.

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.

Anyway, this is pretty off topic, so I'll leave it there.
Paul