"DC (0 hz) assumption"?
wave.py makes the assumption that what the user wants is whatever
happens to be in the file, however arbitrary. (That 8 bit samples are
unsigned bytes is probably an artifact of early ADC logic. Typically you
got an absolute, n-bit value from an old ADC. Newer chips often return
signed values.) It's very unlikely that anything but a copy program
would try to work with unsigned char samples. Too many things to go
wrong. Too much confusion. Zero means zero in most of the world, in and
out of audio processing. :)  That said, not having to offset the 8 bit
samples sparsifies the read/write_sample code. But, I'm thinking that
that's at the expense of every program that uses it. When in doubt, I
figure, do what is more useful. Don't force the caller to write a
wrapper if he'll need to do it 99% of the time. But this is not a
religious thing with me. A wrapper can be written. And, in fact, I'd
sure think it would be nice to include wrappers like auto-scaling and
auto-zeroing in wave.py. But maybe not, as these ops probably belong in
some array.py type module. Anyway, a non-audio guy who just wants to
read a wave file, diddle with it, and write it out. Or who just wants to
generate some sound and write it out. Or who just wants to read a wave
file and graph it or something. All of these guys will be stunned when
they find out to their hours-of-work chagrin that wave files' 8 bit
samples are not signed chars. And, if I were one of them, I'd be plenty
peeved after having to spend all that time learning about some
historical artifact just to read an danged audio file, for gosh sakes.
But not putting the 8-bit offset in the read/write_samples logic does
eliminate 2 lines of code in each routine.

"writesamples would raise an exception"
Yep, taste. I'm inclined to find this irritating and I don't like being
irritated by packages I use. Makes for a poor out-of-box experience.
But, taste. :)

"4) Well, lets fix a format then. else: wavs = [[wav]]" ?
That's an extra [] I think. [[samples]] would be an array of array of an
array of samples. s = [1,2]; print [ [ a ] ];    [[[1,2]]]
On reflection, I'd say I agree with you more than I do with me on the
ability of writesamples() to take a simple array of mono samples. Not a
good thing to do.

"wavs.extend(wav)" ?
I had to look up extend() and try it in the Python shell! :) To each his
own. But when I found out that one could do list+=added_list in Python I
never looked back. Intuitive. I special-cased mono for speed purposes.
No reason to do the +=/extend for mono samples. But, maybe the
interpretor handles all that. Don't know. Didn't measure it.

"monkey patch"?'
Wonderful! This makes your rewrite of the code *so* much cleaner. Thanks
for the tip!

"code layout"?
Har, har. Yep, no one in software has ever spent any time "discussing"
code layout before. Let's do it for the first time in history.

"test_wave.py"?
Oooo. Bit minimal, that. Yeah, I think a couple of things could be
fleshed out there.

Gotta run now. But will try to update the code in wave_futz later. Other
things on plate, though.

Guilherme, I really appreciate your handling this and your guidance. Thanks!