[Python-3000] iostack and Oh Oh

[Guido van Rossum]

First choice: binary files should not be iterable at all. I've never
felt the need for this feature.

Second choice: binary files should iterate given the buffer size
(explicit or default) passed to open(). For unbuffered files they
should iterate over bytes.

On 11/29/06, Bill Janssen <janssen at parc.com> wrote:
> Though I'm not happy with the current factoring of the "file" type at
> http://wiki.python.org/moin/AbstractBaseClasses.  I'm thinking this
> afternoon that there should be an InputStream type and an OutputStream
> type, and that the particular mix of interfaces you get back from
> "open" should depend on what kind of file it is (tty or disk, etc.)
> and the mode that you used to open it.  The actual file classes might
> be hidden; you would look at which interfaces you got to see what you
> could do with it.  Of course, you should get back the right mix for
> the specified mode and file kind!
>
> Incidentally, what kind of iteration should apply to files opened in
> "binary" mode (which I continue to believe should be the default for
> Python)?
>
>   for line in open("foo.jpg", "rb"):
>     ...
>
> just seems wrong to me.  Should be an iteration over bytes of the
> file, or over blocks.  How about 80-byte "records" :-?
>
> Bill
>
> > I would not count on GFs, but I would suggest to count on ABCs and a
> > better hierarchy.
> >
> > E.g. look at what Bill Janssen came up with (clearly incomplete):
> > http://wiki.python.org/moin/AbstractBaseClasses
> >
> > I think that seekability should be a dynamically determined property though.
> >
> > On 11/29/06, tomer filiba <tomerfiliba at gmail.com> wrote:
> > > Guido:
> > > > Agreed that for the distinction between readable/writable it's pretty
> > > > silly, and probably just encourages LBYL code
> > >
> > > no, the point was -- should we use separate StreamReader/StreamWriter
> > > classes, we wouldn't need this querying, the object will fail with
> > > AttributeError/TypeError if we attempt to perform an invalid operation.
> > >
> > > for example:
> > > f = file("...", "w")
> > > f.read() # IOError
> > >
> > > fr = FileWriter(file("...", "w"))
> > > fr.read() # AttributeError
> > >
> > > with all that stricter-interfaces talk, which is likely to enter py3k,
> > > the question we should ask is do we want the new IO stack to make
> > > use of those (or at least be designed with that in mind)?
> > >
> > > if we do want stricter interfaces in the IO stack too, then we
> > > should follow the java-style path (separate readers and writers,
> > > etc.).
> > >
> > > for example, do you think users of the IO stack would want multiple
> > > dispatch based on different streams? i'm well aware that GFs
> > > are not yet finalized material, but do we want to take them into
> > > account? or keep the plain old duck-typed io stack of today?
>
>


-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)