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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
