[Python-3000] iostack and Oh Oh

[Bill Janssen]

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?