On Sat, Aug 8, 2009 at 6:31 PM, Guido van Rossum<guido@python.org> wrote:
In the grander scheme of things, I worry that interpreting byte strings as integers and implementing bitwise operators on them is going to cause more confusion and isn't generally useful enough to
Indeed. But let me rephrase this. I don't know Python, I'm just starting with Py3k, and I see a bytes object. I don't know what a "byte string" is (and I even feel that the term is strange), but I understand that b"b3\xdd" is an array of three bytes, which, of course, is an array of 24 bits (unless I know that bytes are not always octets, but I think it's the same for this case). So, I think that providing bit semantics is a must for bytes objects. I don't care (or I don't know enough to know that this exist) about big/little endian, I just assume that this "just works" (it's is the same case with line ending bytes: I may not know that different OSs finish lines with different marks). *I* (me as Facundo), don't really know enough to be able to propose "what could work and keep surprise to a minimum", but just wanted to present an "end user case" about this.
warrant the extra code. I'd be okay with a standard API to transform a byte array into an integer and vice versa -- there you can be explicit about byte order and what to do about negative numbers. I can't
Yes. Bit arrays and integers suffer (suffer?) from the same issue that Unicode. An integer, and an Unicode character, are encoded into bits... and if you have bits, you need to know how to decode them to get again your Unicode character, or your integer. Maybe we could use the same names? What about something like b"....". decode("little_endian__two's_complement") --> int? (please, very please, better encoding names) Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/