[Python-3000] iostack, second revision

[tomer filiba]

> Why not use tell() and seek() instead of get_pointer() and
> set_pointer()?

because, at least the way i see it, seek and tell are byte-oriented,
while the upper layers of the stack may be objects-oriented
(including, for instance, characters, struct records, or pickled objects),
so pointers would be a vector of (byte-position, stateful object-layer info).

pointers are different than mere byte-positions, so i thought streams
should have a byte-level API, while the upper layers are more likely
to work with "pointers".

[Guido]
> Seek should also support several special cases:
> f.seek(0) seeks to the start of the file no matter what type is
> otherwise used for pointers ("seek cookies" ?), f.seek(0, 1) is a
> no-op, f.seek(0, 2) seeks to EOF.

[Antoine]
> Perhaps it would be good to drop those magic numbers (0, 1, 2) for
> seek() ? They don't really help readibility except perhaps for people
> who still do a lot of C ;)

yes, this was discussed some time ago. we concluded that the new
position property should behave similar to negative indexes:

f.position = 5  --  absolute seek, from the beginning of the stream
f.position += 3  --  relative seek (*)
f.position = -1  -- absolute seeking, back from the end (**)

(*) it requires two syscalls, so we'll also have a seekby() method
(**) like "hello"[-1]

imho it's much more simple and intuitive than these magic consts,
and it feels more like object indexing.


-tomer

On 9/8/06, Guido van Rossum <guido at python.org> wrote:
> On 9/7/06, tomer filiba <tomerfiliba at gmail.com> wrote:
> > lots of things have been discussed, lots of new ideas came:
> > it's time to rethink the design of iostack; i'll try to see into it.
> >
> > there are several key issues:
> > * splitting streams to separate reading and writing sides.
> > * the underlying OS resource can be separated into some very low
> > level abstraction layer, over which streams would operate.
> > * stateful-seek-cookies sound like the perfect solution
> >
> > issues with seeking:
> > being opaque, there's no sense in having the long debated
> > position property (although i really liked it :)). i.e., there's no sense
> > in doing s.position += some_opaque_cookie
> >
> > on the other hand, since streams are byte-oriented, over which the
> > data abstraction layer (text, etc.) is placed, maybe there's sense in
> > splitting these into two distinct APIs:
> >
> > * tell()/seek() for the byte-level stream position: a stream is just a
> > sequence of bytes in which you can seek.
> > * data-abstraction-layer "pointers": pointers will be stateful stream
> > locations of encoded *objects*.
> >
> > you will not be able to "forge" pointers, you'll first have come across
> > a valid object location, and then could you get a "pointer" pointing to it.
> > of course these pointers should be kept cheap, and for most situations,
> > plain integers would suffice.
>
> Using plain ints makes them trivially forgeable though. Not sure I
> mind, just noticing.
>
> > example:
> >
> > f = TextAdapter(BufferingLayer(FileStream(...)), encoding = "utf-32")
> > f.write("hello world")
> > p = f.get_pointer()
> > f.write("wide web")
> > f.set_pointer(p)
>
> Why not use tell() and seek() instead of get_pointer() and
> set_pointer()? Seek should also support several special cases:
> f.seek(0) seeks to the start of the file no matter what type is
> otherwise used for pointers ("seek cookies" ?), f.seek(0, 1) is a
> no-op, f.seek(0, 2) seeks to EOF.
>
> > or using a property:
> > p = f.pointer
> > f.pointer = p
>
> Since the creation of a seek cookie may be relatively expensive (since
> it may have to ask the decoder a rather personal question :-) it
> should be a method, not a property.
>
> > something like that....though i  would like to recv comments on
> > that first, before i go into deeper meditation :)
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>