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