> > See the steps I mentioned. Unless step #1 is completed there is no way
> > to make the following code work:
> >
> > open(Path("foobar"))
> >
> > Well, there is one alternative which is:
> >
> > open(Path("foobar").tostring())
> >
> > And that is a Java-esque workaraound that I think noo
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
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. Ho
[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"))
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 the
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
posixmodul
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
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
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 shou
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 attri
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
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
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 an
13 matches
Mail list logo
