This changes PyArg_ParseTuple()'s "t#" to request a PyBUF_SIMPLE buffer
like all of the other buffer-using format units instead of
PyBUF_CHARACTER. Objects with multi-byte units wind up
byte-order-dependent. Alternately, it might make sense to have
array.array('b') and array.array('B') accept the PyBUF_CHARACTER flag.

I haven't actually tested this patch on a big-endian machine.

Hm, doesn't this make t and t# identical to s and s#?  Or if there are
still differences, are they still relevant?  I vaguely recall that t and
t# were introduced as variants of s and s# that requested char buffers.
 Since we're phasing out the whole idea of char buffers, perhaps there's
no longer a need for the distinction?

Never mind.  s/s# has explicit support for unicode. There is no t; t#
requires a buffer that's not unicode (that's what PyBUF_CHARACTER
amounts to).

If there's one area I'd love to refactor it's getargs.c.
What a sprawling mess!

Also, we should kill PyBUF_CHARACTER completely.

PyBUF_CHARACTER is now gone, and getargs.c reads:

          /*TEO: This can be eliminated --- here only for backward
            compatibility */
        case 't': { /* 8-bit character buffer, read-only access */

I'm not sure what t# is for. Jeffrey, have you tried using y* instead?
(you must call PyBuffer_Release at the end)

I actually have no idea what I was trying to do when I ran into this. I
think it was a use somewhere in the standard libraries rather than my
own code, so if uses of t# are gone from there, I'd have no objections
to closing this bug.