RetroSearch Browse

Wed Feb 22 19:17:51 CET 2006 · https://mail.python.org/pipermail/python-dev/2006-February/061716.html

On 2/20/06, Mark Mc Mahon <mark.m.mcmahon at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20060222/8577a431/attachment.html 

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2006-February/061716.html below:

[Python-Dev] Path PEP: some comments (equality)