> > 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
12 matches
Mail list logo
