On Wed, Mar 30, 2016 at 4:20 AM, Paul Moore firstname.lastname@example.org wrote:
On 30 March 2016 at 09:45, Sven R. Kunze email@example.com wrote:
On 29.03.2016 23:57, Paul Moore wrote:
On 29 March 2016 at 22:00, Sven R. Kunze firstname.lastname@example.org 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
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
datastructure with its convenience methods and the dirty str-like thing
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
* 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: 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 Pythonemail@example.com https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/