Bytes-like objects have some strangeness regarding slicing. But if you provide
only a start, it gives you an int. Any other conditions, it gives you a
bytes-like object. That doesn't translate to our read method which may not be
slicable. So we either need to make sure we always explicitly turn things into
an int when we need them with ord(), or this.
So, this.
If you read one index from a bytes or bytearray, you get an int, not a single
character bytes object. Originally I didn't want to mimic that feature because
it's actually somewhat annoying at times. Realizing it was done that way for a
reason, and not doing it in ByteBuffer is gonna be even more annoying.
We broke str(ByteBuffer) with the util.py commit, but having that return a
possibly megabytes-long string was stupid anyway. It now returns a string just
indicating that it's not really a printable thing rather than the still
probably extremely long repr().
Added a hexdump function to call util.hexdump cleanly. This is really only
here for debugging. I can imagine a lot of things you could do to account for
possibilities later on, but YAGNI applies (including that if you do need it,
you can add it then.)
I'm not sure using a hexdump makes sense for str() here, but I don't know what
else does yet. I also know that I want a buffer to be hexdumpable, although I
think I'd prefer something that allows a hexdump not to require a huge amount
of memory. Until we start processing HFS, I don't need to dwell on that too
much. Let's get it working first.
I explained in the comments on BufferType why I'm doing this, but the nutshell
version is that I anticipate having bigger files to deal with at some point we
won't want to keep in memory. Otherwise we could just use bytearrays.
The way this is meant to be used (which admittedly isn't clear--would someone
like to submit a patch that improves the docs to clarify?) is that this is
intended to be used as a context. In other words, using Python's with
statement. This isn't all that different for a ByteBuffer, but it would be for
a FileBuffer (which doesn't exist yet and won't for awhile.)
Implementation hint for FileBuffer when I get there: If the file is not
explicitly opened read-only, I intend for read-modify-write to be standard
practice from the start. That'll mean duplicating a file to a temporary one we
can manipulate safely and then at flush time, copying the changes over the
original. That way you'd always be able to undo your changes by quitting
without saving. This seems important as blocksfree is likely to serve a lot of
archival duty and you may only get one shot at trying to save an image from a
damaged floppy. It would be awful if that image were then destroyed by an
accidental exception somewhere in the middle of other operations. So let's not
go there.
What this is missing is a flush method. It's not implemented because:
a. cppo is all we've got so far and it doesn't need write at all
b. I'm not 100% sure how I'm doing files yet
c. I'm hoping the way I ought to implement this will make itself apparent when
the code gets used.
