On 2/20/06, Mark Mc Mahon <[EMAIL PROTECTED]> 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 clas
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 re
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_
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 P
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
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 ct
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 t
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 abstraction
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> 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
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
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 cross-plat
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 funda
13 matches
Mail list logo
