Nov-11-2017, 09:07 PM
I see. I suspected something like that looking at source.
However, this behaviour can create some incongruences (tough, I conceal, in some few cases). It could be faster, but... is it really worth it?
If you need to convert "manually" Paths to strings to get a "proper" ordered list of pathlib.Paths (instead of making "automatically" on the package), I do not see real gain. I just see a point of incongruence, weird behaviour, and potential programmer's flaws.
Because I cannot fully understand the algorithm behind pathlib comparations, I cannot say —as you and Larz60+ pointed out— if it is really necessary to convert to a string for comparing internally two Paths. Is not it possible to get an alphabetical order (such as on strings) using internal lists on pathlib implementation itself?
Of course, this is a minor annoyance. I have been working with pathlib since its inception and it is the first time I have encountered this.
Thanks.
However, this behaviour can create some incongruences (tough, I conceal, in some few cases). It could be faster, but... is it really worth it?
If you need to convert "manually" Paths to strings to get a "proper" ordered list of pathlib.Paths (instead of making "automatically" on the package), I do not see real gain. I just see a point of incongruence, weird behaviour, and potential programmer's flaws.
Because I cannot fully understand the algorithm behind pathlib comparations, I cannot say —as you and Larz60+ pointed out— if it is really necessary to convert to a string for comparing internally two Paths. Is not it possible to get an alphabetical order (such as on strings) using internal lists on pathlib implementation itself?
Of course, this is a minor annoyance. I have been working with pathlib since its inception and it is the first time I have encountered this.
Thanks.