Home Original page

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

Wes Turner wes.turner at gmail.com
Wed Mar 30 06:52:41 EDT 2016 
On Wed, Mar 30, 2016 at 4:20 AM, Paul Moore <p.f.moore at gmail.com> wrote:

> 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.
>

Really, these are actual graph paths sequences

Because:

* 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:

   ./path/
   ./path


>
> 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:
https://github.com/jaraco/path.py/blob/master/path.py


>
> Anyway, this is pretty off topic, so I'll leave it there.
> Paul
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160330/28e2232d/attachment-0001.html>
More information about the Python-ideas mailing list