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__
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
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
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
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
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
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
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
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
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
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
11 matches
Mail list logo