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