Le dimanche 07 février 2010 à 09:54 +0100, Pascal Chambon a écrit :
> > Actually, TextIOWrapper is simply not thread-safe for most of its
> > operations. I
> > think we did the work for simple writing, though, since it's better for
> > multi-threaded use of print().
>
> Argh, I had the impression
Pascal Chambon gmail.com> writes:
>
> The problem is, doing that forwarding is quite complicated.
Hmm, why is it complicated? I agree it can be tedious (especially in C), but it
doesn't seem complicated in itself.
> My own FileIO class alas needs locking, because for example, on windows
> trunc
On Fri, Feb 5, 2010 at 10:28 PM, Antoine Pitrou wrote:
> Pascal Chambon gmail.com> writes:
>>
>> By the way, I'm having trouble with the "name" attribute of raw files,
>> which can be string or integer (confusing), ambiguous if containing a
>> relative path, and which isn't able to handle the new
Antoine Pitrou a écrit :
What is the difference between "file handle" and a regular C file descriptor?
Is it some Windows-specific thing?
If so, then perhaps it deserves some Windows-specific attribute ("handle"?).
At the moment it's windows-specific, but it's not impossible that some
othe
On Sat, Feb 6, 2010 at 4:31 PM, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Antoine Pitrou wrote:
>> Pascal Chambon gmail.com> writes:
>>> By the way, I'm having trouble with the "name" attribute of raw files,
>>> which can be string or integer (confusing), ambiguous
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Antoine Pitrou wrote:
> Pascal Chambon gmail.com> writes:
>> By the way, I'm having trouble with the "name" attribute of raw files,
>> which can be string or integer (confusing), ambiguous if containing a
>> relative path, and which isn't able to ha
On Fri, Feb 5, 2010 at 3:47 PM, Christian Heimes wrote:
> I had the idea to add a property that returns the file name based on the
> file descriptor. However there isn't a plain way to lookup the file
> based on the fd on POSIX OSes. fstat() returns only the inode and
> device. The combination of
Guido van Rossum wrote:
> You're right, I didn't see the OP's comma. :-)
>
> I don't think this can be helped though -- I really don't want open()
> to be slowed down or complicated by an attempt to do path
> manipulation. If this matters to the app author they should use
> os.path.abspath() or os
On Fri, Feb 5, 2010 at 8:46 AM, wrote:
> On 03:57 pm, gu...@python.org wrote:
>>
>> On Fri, Feb 5, 2010 at 5:28 AM, Antoine Pitrou
>> wrote:
>>>
>>> Pascal Chambon gmail.com> writes:
By the way, I'm having trouble with the "name" attribute of raw files,
which can be string or int
On 03:57 pm, gu...@python.org wrote:
On Fri, Feb 5, 2010 at 5:28 AM, Antoine Pitrou
wrote:
Pascal Chambon gmail.com> writes:
By the way, I'm having trouble with the "name" attribute of raw
files,
which can be string or integer (confusing), ambiguous if containing a
relative path,
Why is
On Fri, Feb 5, 2010 at 5:28 AM, Antoine Pitrou wrote:
> Pascal Chambon gmail.com> writes:
>>
>> By the way, I'm having trouble with the "name" attribute of raw files,
>> which can be string or integer (confusing), ambiguous if containing a
>> relative path,
Why is it ambiguous? It sounds like yo
Pascal Chambon gmail.com> writes:
>
> By the way, I'm having trouble with the "name" attribute of raw files,
> which can be string or integer (confusing), ambiguous if containing a
> relative path, and which isn't able to handle the new case of my
> library, i.e opening a file from an existing
12 matches
Mail list logo
