On Jun 17, 7:55 am, Ned Deily wrote:
> In article ,
> Chris Torek wrote:
>
> > >Steven D'Aprano wrote:
> > >> Why do you think there's no Path object in the standard library? *wink*
>
> > In article
> > Ethan Furman wrote:
> > >Because I can't find one in either 2.7 nor 3.2, and every referen
In article ,
Chris Torek wrote:
> >Steven D'Aprano wrote:
> >> Why do you think there's no Path object in the standard library? *wink*
>
> In article
> Ethan Furman wrote:
> >Because I can't find one in either 2.7 nor 3.2, and every reference I've
> >found has indicated that the other Path
Chris Torek wrote:
Steven D'Aprano wrote:
Why do you think there's no Path object in the standard library? *wink*
In article
Ethan Furman wrote:
Because I can't find one in either 2.7 nor 3.2, and every reference I've
found has indicated that the other Path contenders were too
all-encompa
On Fri, Jun 17, 2011 at 2:32 AM, Christian Heimes wrote:
> "c:d" is a valid directory name on Linux. :]
>
The different naming rules come in handy now and then. Wine creates
directories (symlinks, I think, but same diff) called "c:" and "d:"
and so on, which then become the drives that Windows pr
>Steven D'Aprano wrote:
>> Why do you think there's no Path object in the standard library? *wink*
In article
Ethan Furman wrote:
>Because I can't find one in either 2.7 nor 3.2, and every reference I've
>found has indicated that the other Path contenders were too
>all-encompassing.
What I t
On Thu, Jun 16, 2011 at 10:41 AM, Steven D'Aprano
wrote:
>
> On a Linux or OS X box, you could have a file e inside a directory c:d
> inside b inside a. It can't be treated as platform independent, because
> c:d is not a legal path component under classic Mac or Windows.
>
> On a classic Mac (does
Steven D'Aprano wrote:
On Thu, 16 Jun 2011 09:16:22 -0700, Ethan Furman wrote:
Steven D'Aprano wrote:
If Path is intended to be platform independent, then these two paths
could represent the same location:
'a/b/c:d/e' # on Linux or OS X
'a:b:c/d:e' # on classic Mac pre OS X
and be impossib
Christian Heimes wrote:
Am 16.06.2011 18:16, schrieb Ethan Furman:
Steven D'Aprano wrote:
If Path is intended to be platform independent, then
these two paths could represent the same location:
'a/b/c:d/e' # on Linux or OS X
'a:b:c/d:e' # on classic Mac pre OS X
and be impossible on Window
On Thu, 16 Jun 2011 09:16:22 -0700, Ethan Furman wrote:
> Steven D'Aprano wrote:
>> If Path is intended to be platform independent, then these two paths
>> could represent the same location:
>>
>> 'a/b/c:d/e' # on Linux or OS X
>> 'a:b:c/d:e' # on classic Mac pre OS X
>>
>> and be impossible o
Am 16.06.2011 18:16, schrieb Ethan Furman:
> Steven D'Aprano wrote:
>> If Path is intended to be platform independent, then
>> these two paths could represent the same location:
>>
>> 'a/b/c:d/e' # on Linux or OS X
>> 'a:b:c/d:e' # on classic Mac pre OS X
>>
>> and be impossible on Windows. So w
Steven D'Aprano wrote:
If Path is intended to be platform independent, then
these two paths could represent the same location:
'a/b/c:d/e' # on Linux or OS X
'a:b:c/d:e' # on classic Mac pre OS X
and be impossible on Windows. So what's the canonical path it should be
converted to?
Are the
Steven D'Aprano wrote:
On Wed, 15 Jun 2011 19:00:07 -0700, Ethan Furman wrote:
Thread 1: "objects of different types compare unequal" self:
"nonsense! we have the power to say what happens in __eq__!"
Thread 2: "objects that __hash__ the same *must* compare __eq__!" self:
"um, what? .
On Thu, 16 Jun 2011 09:03:58 +0200, Laurent Claessens wrote:
>> So, I suppose I shall have to let go of my dreams of
>>
>> --> Path('/some/path/and/file') == '\\some\\path\\and\\file'
>>
>> and settle for
>>
>> --> Path('...') == Path('...')
>>
>> but I don't have to like it. :(
>
>
> Why not
On Wed, 15 Jun 2011 19:00:07 -0700, Ethan Furman wrote:
> Thread 1: "objects of different types compare unequal" self:
> "nonsense! we have the power to say what happens in __eq__!"
>
> Thread 2: "objects that __hash__ the same *must* compare __eq__!" self:
>"um, what? ... wait, only im
So, I suppose I shall have to let go of my dreams of
--> Path('/some/path/and/file') == '\\some\\path\\and\\file'
and settle for
--> Path('...') == Path('...')
but I don't have to like it. :(
Why not define the hash method to first convert to '/some/path/and/file'
and then hash ?
By
In my continuing quest for Python Mastery (and because I felt like it ;)
I decided to code a Path object so I could dispense with all the
os.path.join and os.path.split and os.path.splitext, etc., etc., and so
forth.
While so endeavoring a couple threads came back and had a friendly
little ch
16 matches
Mail list logo
