BJörn Lindqvist [EMAIL PROTECTED] writes:
[M.-A. Lemburg]
I don't see why this is critical for the success of the Path
object. I agree with Thomas that interfaces should be made
compatible to Path object.
See the steps I mentioned. Unless step #1 is completed there is no way
to make the
[M.-A. Lemburg]
I don't see why this is critical for the success of the Path
object. I agree with Thomas that interfaces should be made
compatible to Path object.
See the steps I mentioned. Unless step #1 is completed there is no way
to make the following code work:
open(Path(foobar))
Ian Bicking [EMAIL PROTECTED] wrote:
OTOH, str(path) will break unicode filenames. And unicode()
breaks anything that simply desires to pass data through without
effecting its encoding.
That general problem was the motivation for PEP 349. Originally I
suggested adding a new built-in.
This seems to be the only really major issue with the PEP. Everything
else is negotiable, IMHO. But the string inheritance seem to be such a
critical issue it deserves its own thread. I have tried to address all
criticism of it here:
Really, it is the same arguments that have been rehashed over
BJörn Lindqvist wrote:
However, I might be wrong because according to [1] it should work. And
having to wrap the Path object in str() (open(str(somepath))) each and
every time the called function expects a string is not a practical
solution.
in Python, the usual way to access an attribute of
BJörn Lindqvist wrote:
This seems to be the only really major issue with the PEP. Everything
else is negotiable, IMHO. But the string inheritance seem to be such a
critical issue it deserves its own thread. I have tried to address all
criticism of it here:
I don't see why this is critical for
Fredrik Lundh wrote:
However, I might be wrong because according to [1] it should work. And
having to wrap the Path object in str() (open(str(somepath))) each and
every time the called function expects a string is not a practical
solution.
in Python, the usual way to access an attribute of an
BJörn Lindqvist wrote:
This seems to be the only really major issue with the PEP.
I'd like to call for order here. What PEP? I can't find it
on
http://www.python.org/peps/
Also, if this is a major issue, then the PEP owner should not
start a thread discussing it, but instead edit the PEP
M.-A. Lemburg wrote:
Please note that inheritance from string will cause the C type
checks of the form PyString_Check(obj) to return true.
C code will then assume that it has an object which is
compatible to string C API which instances aren't.
Oh, sure they are. Types inheriting from str
Ian Bicking wrote:
Fredrik Lundh wrote:
However, I might be wrong because according to [1] it should work. And
having to wrap the Path object in str() (open(str(somepath))) each and
every time the called function expects a string is not a practical
solution.
in Python, the usual way to access
On Thu, Jan 26, 2006 at 07:55:08PM +, Steve Holden wrote:
Would it help to redefine file/open so they called an __open__() method
on the argument were one defined, otherwise reverting to current behaviour?
Not really, open() is (by far!) not the only function that breaks. Most
posixmodule
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
Please note that inheritance from string will cause the C type
checks of the form PyString_Check(obj) to return true.
C code will then assume that it has an object which is
compatible to string C API which instances aren't.
Oh, sure they are.
12 matches
Mail list logo
