You are proposing a bit array. Whether the bits are interpreted or displayed as 0/1 or f/t or False/True is secondary. The problem is that bit arrays do not fit the array model, with its minimum byte size per element of 1. There are other aspects of arrays that do not fit either. What would .itemsize() return? fractions. Fraction(1,8)? In any case, the internal implementation will be substantially different.

So I suggest that the proposal be to add an array.bitarray class. The bit representation strings '0'/'1', 'f'/'t', 'False'/'True' could be parameters. Omit typecode, typecodes, amd itemsize attributes and byteswap and (to or from)string methods. The buffer_info method would need redefinition. Should (to/from)(bytes/file) use 1 byte per bit (is so, which ones) or pack 8 bits per byte? It would be sensible to add bitwise operators (~, &, |, ^) on bit arrays of the same length. An implementation decision is the granularity of the internal storage (1, 2, 4, or possibly 8 bytes on 64 bit systems -- or just use 3.x ints).  The insert/delete methods might be omitted, but implementation of such should be similar to the shift methods for integers, which have the same problem of moving bits between internal implementation chunks.

I suspect that many have implemented versions of this in Python (as well as other languages) using bytes or ints with masks. I suggest you present the idea on python-ideas list to garner more support -- and be prepred to write a PEP for a new class.

I suspect that the relative ease of using ints as bit arrays will be an argument against such an addition. That is why they have the bit operations. On the other hand, one might argue that the inclusion of bit operations acknowledges the need for bit arrays.