![](https://secure.gravatar.com/avatar/9849f374cf2c66cb4232091309f309de.jpg?s=120&d=mm&r=g)
Hi, It seems that the Path module as currently defined leaves equality testing up to the underlying string comparison. My guess is that this is fine for Unix (maybe not even) but it is a bit lacking for Windows. Should the path class implement an __eq__ method that might do some of the following things: - Get the absolute path of both self and the other path - normcase both - now see if they are equal This would make working with paths much easier for keys of a dictionary on windows. (I frequently use a case insensitive string class for paths if I need them to be keys of a dict.) My first email to python-dev :-) Mark
![](https://secure.gravatar.com/avatar/8341c5bff3dcbd8ed34d9d68bd4169f2.jpg?s=120&d=mm&r=g)
On 2/20/06, Mark Mc Mahon <mark.m.mcmahon@gmail.com> wrote:
It seems that the Path module as currently defined leaves equality testing up to the underlying string comparison. My guess is that this is fine for Unix (maybe not even) but it is a bit lacking for Windows.
Should the path class implement an __eq__ method that might do some of the following things: - Get the absolute path of both self and the other path - normcase both - now see if they are equal
This has been suggested to me many times. Unfortunately, since Path is a subclass of string, this breaks stuff in weird ways. For example: 'x.py' == path('x.py') == path('X.PY') == 'X.PY', but 'x.py' != 'X.PY' And hashing needs to be consistent with __eq__: hash('x.py') == hash(path('X.PY')) == hash('X.PY') ??? Granted these problems would only pop up in code where people are mixing Path and string objects. But they would cause really obscure bugs in practice, very difficult for a non-expert to figure out and fix. It's safer for Paths to behave just like strings. -j
![](https://secure.gravatar.com/avatar/72ee673975357d43d79069ac1cd6abda.jpg?s=120&d=mm&r=g)
Mark Mc Mahon wrote:
Should the path class implement an __eq__ method that might do some of the following things: - Get the absolute path of both self and the other path
I don't think that any path operations should implicitly touch the file system like this. The paths may not represent real files or may be for a system other than the one the program is running on.
- normcase both
Not sure about this one either. When dealing with remote file systems, it can be hard to know whether a path will be interpreted as case-sensitive or not. This can be a problem even with local filesystems, e.g. on MacOSX where you can have both HFS (case-insensitive) and Unix (case-sensitive) filesystems mounted. -- Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | greg.ewing@canterbury.ac.nz +--------------------------------------+
![](https://secure.gravatar.com/avatar/694bbd7f4420b0874e3577f1fd5dd28a.jpg?s=120&d=mm&r=g)
On 2/20/06, Mark Mc Mahon <mark.m.mcmahon@gmail.com> wrote:
Hi,
It seems that the Path module as currently defined leaves equality testing up to the underlying string comparison. My guess is that this is fine for Unix (maybe not even) but it is a bit lacking for Windows.
Should the path class implement an __eq__ method that might do some of the following things: - Get the absolute path of both self and the other path - normcase both - now see if they are equal
This would make working with paths much easier for keys of a dictionary on windows. (I frequently use a case insensitive string class for paths if I need them to be keys of a dict.)
The PEP specifies path.samefile(), which is useful in the case of files that actually exist, but pretty much useless for comparing paths that don't exist on the local machine. I think leaving __eq__ as the default string comparison is best. But what about providing an alternate platform-specific equality test? def isequal(self, other, platform="native"): """Return True if self is equivalent to other using platform's path comparison rules. platform can be one of "native", "posix", "windows", "mac".""" This could do some combination of os.path.normpath() and os.path.normcase() depending on the platform. The docs for os.path.normpath() say that it may change the meaning of the path if it contains symlinks...it's not clear to me how though. Cheers, Chris
participants (4)
-
Chris AtLee
-
Greg Ewing
-
Jason Orendorff
-
Mark Mc Mahon