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

2006-02-22 Thread Jason Orendorff
On 2/20/06, Mark Mc Mahon [EMAIL PROTECTED] wrote: It seems that the Path module as currently defined leaves equalitytesting up to the underlying string comparison. My guess is that thisis fine for Unix (maybe not even) but it is a bit lacking for Windows. Should the path class implement an __eq__

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

2006-02-22 Thread Greg Ewing
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

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

2006-02-21 Thread Mark Mc Mahon
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

Re: [Python-Dev] Path PEP: some comments

2006-02-08 Thread Andy Teijelo Pérez
El Sábado, 4 de Febrero de 2006 2:35, Giovanni Bajo escribió: Hello, my comments on the Path PEP: - Many methods contain the word 'path' in them. I suppose this is to help transition from the old library to the new library. But in the context of a new Python user, I don't think that

Re: [Python-Dev] Path PEP: some comments

2006-02-05 Thread Martin v. Löwis
Phillip J. Eby wrote: - ctime() is documented to be unportable: it has different semantics on UNIX and Windows. I believe the class should abstract from these details. Note that this is the opposite of normal Python policy: Python does not attempt to create cross-platform abstractions, but

Re: [Python-Dev] Path PEP: some comments

2006-02-05 Thread Martin v. Löwis
Terry Reedy wrote: Note that this is the opposite of normal Python policy: Python does not attempt to create cross-platform abstractions, but instead chooses to expose platform differences. I had the opposite impression about Python -- that it generally masks such differences. I think it

Re: [Python-Dev] Path PEP: some comments

2006-02-05 Thread Giovanni Bajo
On Sun, February 5, 2006 13:57, Martin v. Löwis wrote: I think the path module should provide these under a different name: creation_time and status_change_time. Either of these might be absent. +1. This is exactly what I proposed, in fact. ctime should be provided to report whatever ctime

Re: [Python-Dev] Path PEP: some comments

2006-02-05 Thread Martin v. Löwis
Giovanni Bajo wrote: ctime should be provided to report whatever ctime used to report in the past (i.e. creation_time on Windows, status_change_time on Unix). In other words, if there are mistakes in the old API, this is the time to fix them. Why should we carry them over to a new API? I'm

[Python-Dev] Path PEP: some comments

2006-02-04 Thread Giovanni Bajo
Hello, my comments on the Path PEP: - Many methods contain the word 'path' in them. I suppose this is to help transition from the old library to the new library. But in the context of a new Python user, I don't think that Path.abspath() is optimal. Path.abs() looks better. Maybe it's not so

Re: [Python-Dev] Path PEP: some comments

2006-02-04 Thread Phillip J. Eby
At 08:35 PM 2/4/2006 +0100, Giovanni Bajo wrote: - ctime() is documented to be unportable: it has different semantics on UNIX and Windows. I believe the class should abstract from these details. Note that this is the opposite of normal Python policy: Python does not attempt to create

Re: [Python-Dev] Path PEP: some comments

2006-02-04 Thread Giovanni Bajo
Phillip J. Eby [EMAIL PROTECTED] wrote: - ctime() is documented to be unportable: it has different semantics on UNIX and Windows. I believe the class should abstract from these details. Note that this is the opposite of normal Python policy: Python does not attempt to create cross-platform