> This [text/binary] distinction is
> supported by the basic file operations in the C library. To open a
> text file in binary mode is technically an error (although in many OSs
> you'll get away with it).
It's one of those "technical" errors that really isn't an error (from
Python). On the other
On 9/13/05, Michael Chermside <[EMAIL PROTECTED]> wrote:
> In unix, the above is true. One of the fundamental decisions in Unix
> was to treat all files (and lots of other vaguely file-like things)
> as undiferentiated streams of bytes. But this is NOT true on many
> other operating systems. It is
Andrew Durdin writes:
> Another area where I think this approach can help is with the
> text/binary file distinction. file() could always open files as
> binary, and there could be a convenience function textfile(name, mode)
> which would simply return textstream(file(name, mode)). This would
> rem
On 9/13/05, Andrew Durdin <[EMAIL PROTECTED]> wrote:
> On 9/6/05, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> >
> > One could use "class decorators". For example if you want to define the
> > method foo() in a file-like class, you could use code like:
>
> I like the sound of this. Suppose there we
On 9/6/05, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>
> One could use "class decorators". For example if you want to define the
> method foo() in a file-like class, you could use code like:
I like the sound of this. Suppose there were a function textstream()
that decorated a file-like object (su
On 9/6/05, Steven Bethard <[EMAIL PROTECTED]> wrote:
> I'd also prefer something along the lines of Fredrik's suggestion, but
> I don't write enough C code to understand Paul's last point. Could
> someone briefly explain why mixins wouldn't work in C code?
I had in mind "it would be complicated a
Steven Bethard wrote:
> Could
> someone briefly explain why mixins wouldn't work in C code?
Depends on what you mean by "work in C code". It's only
possible for a type object to inherit C struct members
from one base class, since the struct has to be an
extension of the base C struct. Dynamic att
[Greg Ewing]
> While we're on the subject, in Py3k I'd like to see
> readline(), readlines(), etc. removed from file objects
> and made builtin functions instead. It should only
> be necessary to implement read() and write() to get
> a file-like object having equal status with all
> others.
[Fredr
> That sounds like a good idea. I'm certainly getting concerned about
> the proliferation of methods that people "should" add to file-like
> objects, where read/write are the only fundamental ones needed.
>
> I can't see mixins working, as too many file-like objects are written in C...
One could
Fredrik Lundh wrote:
> maybe some variation of
>
> http://www.python.org/peps/pep-0246.html
>
> combined with "default adapters" could come in handy here ?
I really hope we can get by with something much less
heavyweight than that. I'm far from convinced that
something like PEP 246 proposes
On 9/6/05, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Greg Ewing wrote:
> > While we're on the subject, in Py3k I'd like to see
> > readline(), readlines(), etc. removed from file objects
> > and made builtin functions instead. It should only
> > be necessary to implement read() and write() to get
Greg Ewing wrote:
>> (you completely missed the point -- today's print mechanism works on *any*
>> object
>> that implements a "write" method, no just file objects. saying that "oh,
>> all you need is
>> to add a method" or "here's a nice mixin" doesn't give you a print
>> replacement)
>
> Whi
Fredrik Lundh wrote:
> (you completely missed the point -- today's print mechanism works on *any*
> object
> that implements a "write" method, no just file objects. saying that "oh, all
> you need is
> to add a method" or "here's a nice mixin" doesn't give you a print
> replacement)
While we'
13 matches
Mail list logo
