Talin wrote:
> Ideally, you should be able to pass
> "file:///..." to a regular "open" function.
I'm not so sure about that. Consider that "file:///foo.bar"
is a valid relative pathname on Unix to a file called "foo.bar"
in a directory called "file:".
That's not to say there shouldn't be a funct
Greg Ewing wrote:
> Talin wrote:
>> (Actually, the OOP approach has a slight advantage in terms of the
>> amount of syntactic sugar available,
>
> Even if you don't use any operator overloading, there's
> still the advantage that an object provides a namespace
> for its methods. Without that, you
Talin wrote:
> (Actually, the OOP approach has a slight advantage in terms of the
> amount of syntactic sugar available,
Even if you don't use any operator overloading, there's
still the advantage that an object provides a namespace
for its methods. Without that, you either have to use
fairly ver
Martin v. Löwis wrote:
> Georg Brandl schrieb:
>> Perhaps you can bring up a discussion on python-dev about your improvements
>> and how they could be integrated into the standard library...
>
> Let me second this. The compiler package is largely unmaintained and
> was known to be broken (and per
Talin wrote:
>> You probably want to use the posixpath module directly in that case,
>> though perhaps you've already discovered that.
>
> Never heard of it. Its not in the standard library, is it? I don't see
> it in the table of contents or the index.
http://effbot.org/librarybook/posixpath.
At 10:16 AM 10/25/2006 -0700, Talin wrote:
>Phillip J. Eby wrote:
> > At 09:49 AM 10/25/2006 -0700, Talin wrote:
> >> Having done a path library myself (in C++, for our code base at work),
> >> the trickiest part is getting the Windows path manipulations right, and
> >> fitting them into a model th
On Wednesday 25 October 2006 13:16, Talin wrote:
> Never heard of it. Its not in the standard library, is it? I don't see
> it in the table of contents or the index.
This is a documentation bug. :-( I'd thought they were mentioned
*somewhere*, but it looks like I'm wrong.
os.path is an alias
Phillip J. Eby wrote:
> At 09:49 AM 10/25/2006 -0700, Talin wrote:
>> Having done a path library myself (in C++, for our code base at work),
>> the trickiest part is getting the Windows path manipulations right, and
>> fitting them into a model that allows writing of platform-agnostic code.
>> This
At 09:49 AM 10/25/2006 -0700, Talin wrote:
>Having done a path library myself (in C++, for our code base at work),
>the trickiest part is getting the Windows path manipulations right, and
>fitting them into a model that allows writing of platform-agnostic code.
>This is especially vexing when you r
Nick Coghlan wrote:
> Talin wrote:
>> Part 3: Does this mean that the current API cannot be improved?
>>
>> Certainly not! I think everyone (well, almost) agrees that there is
>> much room for improvement in the current APIs. They certainly need to
>> be refactored and recategorized.
>>
>> But I
Mike Krell schrieb:
>> Based on the behaviour of str and the fact that overriding unicode.__repr__
>> works just fine, I'd say file a bug on SF.
>
> Done. This is item 1583863.
Of course, it would be even better if you could also include a patch.
Regards,
Martin
Talin wrote:
> Part 3: Does this mean that the current API cannot be improved?
>
> Certainly not! I think everyone (well, almost) agrees that there is much
> room for improvement in the current APIs. They certainly need to be
> refactored and recategorized.
>
> But I don't think that the soluti
Mike Krell wrote:
>> class S(str):
>> def __str__(self): return "S.__str__"
>>
>> class U(unicode):
>> def __str__(self): return "U.__str__"
>>
>> print str(S())
>> print str(U())
>>
>> This script prints:
>>
>> S.__str__
>> U.__str__
>
> Yes, but "print U()" prints nothing, and the explic
Scott Dial wrote:
> [EMAIL PROTECTED] wrote:
>> Talin writes:
>> > (one additional postscript - One thing I would be interested in is
>> an > approach that unifies file paths and URLs so that there is a
>> consistent > locator scheme for any resource, whether they be in a
>> filesystem, on a
Scott Dial writes:
> [EMAIL PROTECTED] wrote:
> > Talin writes:
> > > (one additional postscript - One thing I would be interested in is an
> > > approach that unifies file paths and URLs so that there is a consistent
> > > locator scheme for any resource, whether they be in a filesystem,
15 matches
Mail list logo
