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, on a
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 web server,
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 explicit str() should not
be
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 solution is
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
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 don't think
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
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 is
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
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 that allows
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.htm
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 perhaps
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
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 either
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 function
15 matches
Mail list logo
