[Python-3000] iostack, second revision

[Guido van Rossum]

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/)