tomer filiba wrote:
>> FileReader would be an InputStream,
>> FileWriter would be an OutputStream
>
> yes, this has been discussed, but that's too java-ish by nature.
> besides, how would this model handle a simple operation, such as
> file("foo", "w+") ?
You mean, with the intent of both reading and writing to the file in
the same go? That's what I meant FileBytes for. Do you have a
requirement for drop-in compatibility with the current I/O?
In all my programming days I don't believe I written to and read from
the same file handle even once. Use cases exist, like if you're
implementing a DBMS, or adding to a zip file in-place, but they're the
exception, and by separating that functionality out in a dedicated
class like FileBytes, you avoid having the complexities of mixed input
and output affect your typical use cases.
> the reason is some streams, like pipes or partially shutdown()ed-
> sockets may be unidirectional; some (i.e., sockets) may not support
> seeking -- but the 2nd layer may augment that. for example, the
> BufferingLayer may add seeking (it already supports unreading).
Watch out! There's an essentiel difference between files and
bidirectional communications channels that you need to take into
account. For a TCP connection, input and output can be seen as
isolated from one another, with each their own stream position, and
each their own contents. For read/write files, it's a whole different
ballgame, because stream position and data are shared.
That means you cannot use the same buffering code for both cases. For
files, whenever you write something, you need to take into account
that that may overlap your read buffer or change read position. You
should take another look at layer.BufferingLayer with that in mind.
regards, Anders
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
