Re: [Python-Dev] bytes thoughts
Josiah Carlson [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Christos Georgiou [EMAIL PROTECTED] wrote: [Christos] Well, what's the result of bytes([1,0,0])^ bytes([1,0]) ? Is it bytes([0,0,0]) (à la little-endian) or is it bytes([1,1,0]) (straight conversion to base-256)? Or perhaps throw a ValueError if the sizes differ? [Josiah] It's a ValueError. If the sizes matched, it would be a per-element bitwise xor. I agree (in the face of ambiguity...), although I understand that it wasn't obvious that I do from the way I asked the question, which I was expecting Greg to answer :) [Christos] These details should be considered in the PEP. [Josiah] They aren't considered because they are *obvious* to most (if not all) sane people who use Python. I beg to disagree. I don't know whether you are Dutch or not, but most of the Python users aren't; one of the reason PEPs exist is to explain what *should* be obvious at first when one is Dutch ;-) Apart from joking, PEPs should be a record of beating/thinking the PEP subject to its death: The PEP author is responsible for building consensus within the community and documenting dissenting opinions. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bytes thoughts
Christos Georgiou [EMAIL PROTECTED] wrote: [Christos] These details should be considered in the PEP. [Josiah] They aren't considered because they are *obvious* to most (if not all) sane people who use Python. I beg to disagree. I don't know whether you are Dutch or not, but most of There's probably a bit of dutch in me, but likely not sufficient to alter my language intuitions. the Python users aren't; one of the reason PEPs exist is to explain what *should* be obvious at first when one is Dutch ;-) Apart from joking, PEPs should be a record of beating/thinking the PEP subject to its death: The PEP author is responsible for building consensus within the community and documenting dissenting opinions. Considering your quote, I have thusfar not seen any opinion dissenting from what I stated as 'obvious' behavior. As I told Michael Chermside off-list: Sure, great, clarify it. I wasn't saying anything in regards to whether it should or shouldn't [be clarified], just why it probably wasn't already. Also considering that I lack SVN commit permission, it's not within my power to clarify the PEP. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bytes thoughts
Greg Ewing [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Baptiste Carvello wrote: [Baptiste] while manipulating binary data will happen mostly with bytes objects, some operations are better done with ints, like the bit manipulations with the |~^ operators. [Greg] Why not just support bitwise operations directly on the bytes object? Well, what's the result of bytes([1,0,0])^ bytes([1,0]) ? Is it bytes([0,0,0]) (à la little-endian) or is it bytes([1,1,0]) (straight conversion to base-256)? Or perhaps throw a ValueError if the sizes differ? These details should be considered in the PEP. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bytes thoughts
Christos Georgiou [EMAIL PROTECTED] wrote: Well, what's the result of bytes([1,0,0])^ bytes([1,0]) ? Is it bytes([0,0,0]) (à la little-endian) or is it bytes([1,1,0]) (straight conversion to base-256)? Or perhaps throw a ValueError if the sizes differ? It's a ValueError. If the sizes matched, it would be a per-element bitwise xor. These details should be considered in the PEP. They aren't considered because they are *obvious* to most (if not all) sane people who use Python. Think of future bytes behavior to be similar to current array behavior, with a few bits and pieces added to make life easier (like all of the current string methods, etc.) - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bytes thoughts
Josiah Carlson a écrit : They aren't considered because they are *obvious* to most (if not all) sane people who use Python. They are not *that* obvious. Logical operations on ints have allowed users to forget about size (and shoot themselves in the foot from time to time). Or is 1^(~1) == -1 obvious ? Well, maybe that's not sane either :-) Think of future bytes behavior to be similar to current array behavior, with a few bits and pieces added to make life easier (like all of the current string methods, etc.) I didn't get before that the array behavior really *defined* the bytes behavior. OK, I'll keep that in mind. Cheers, BC ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bytes thoughts
Christos Georgiou wrote: Well, what's the result of bytes([1,0,0])^ bytes([1,0]) ? Is it bytes([0,0,0]) (à la little-endian) or is it bytes([1,1,0]) (straight conversion to base-256)? Or perhaps throw a ValueError if the sizes differ? In the interests of refusing the temptation to guess, I'd go for the ValueError. Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bytes thoughts
Baptiste Carvello [EMAIL PROTECTED] wrote: Josiah Carlson a écrit : They aren't considered because they are *obvious* to most (if not all) sane people who use Python. They are not *that* obvious. Logical operations on ints have allowed users to forget about size (and shoot themselves in the foot from time to time). Or is 1^(~1) == -1 obvious ? Well, maybe that's not sane either :-) I find most operations involving ~ to be insane (just a personal opinion), but in this case, if one assumes two's compliment arithmetic (which seems fairly reasonable considering current standard platforms), an integer, all of whose bits are 1, dictates that the value be -1. An insane use of ~, but a sane result. *shrug* - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bytes thoughts
Baptiste Carvello wrote: They are not *that* obvious. Logical operations on ints have allowed users to forget about size (and shoot themselves in the foot from time to time). Or is 1^(~1) == -1 obvious ? Well, maybe that's not sane either :-) It's about as sane as you can get in a world where ints don't have any fixed size. Bytes objects will have a size, on the other hand, and it makes sense to take notice of it. BTW, is anyone else bothered that the term bytes object is a bit cumbersome? Also confusing as to whether it's singular or plural. Could we perhaps call it a bytevector or bytearray or something? Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bytes thoughts
On 3/16/06, Greg Ewing [EMAIL PROTECTED] wrote: BTW, is anyone else bothered that the term bytes object is a bit cumbersome? Also confusing as to whether it's singular or plural. Could we perhaps call it a bytevector or bytearray or something? Doesn't really bother me. You could call it a bytes array (especially since I expect it will start off as a subclass of the array.array class). I'd still like the built-in name to be 'bytes'. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bytes thoughts
Greg Ewing wrote: Baptiste Carvello wrote: while manipulating binary data will happen mostly with bytes objects, some operations are better done with ints, like the bit manipulations with the |~^ operators. Why not just support bitwise operations directly on the bytes object? +1! Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bytes thoughts
Greg Ewing a écrit : Why not just support bitwise operations directly on the bytes object? Sure, what counts is that all the nice features that Python has for editing binary data are usable with the bytes object. These include bitwise operations, hex() and oct() representation functions and litterals, the struct module (as Paul Svensson kindly reminded me). Do I forget something ? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bytes thoughts
some more thoughts about the bytes object: 1) it would be nice to have an trivial way to change a bytes object to an int / long, and vice versa. Rationale: while manipulating binary data will happen mostly with bytes objects, some operations are better done with ints, like the bit manipulations with the |~^ operators. So we should make sure there is no impedance mismatch between those 2 ways of editing binary data. Getting an individual byte at a time is not sufficient, because the part of the data you want to edit might span over a few bytes, or simply fall across a byte boundary. Toy implementation: class bytes(list): ... def from_int(cls, value, length): ... return cls([(value 8*i) % 256 for i in range(length)[::-1]]) ... from_int=classmethod(from_int) ... def int(self): ... return sum([256**i*n for i,n in enumerate(self[::-1])]) ... The length argument to from_int is necessary to create a fixed number of bytes, event if those bytes are 0. Use case: let's say you have a binary record made of 7 bits of padding and 3x3 bytes of unix permissions. You want to change the user permissions, and store the record back to a bytes object: record=bytes([1,36]) # this could be a slice of a preexisting bytes object perms=record.int() print oct(perms) 0444 perms =~( 7 6 ) # clear the bits corresponding to user permissions perms |= 6 6 # set the bits to the new value print oct(perms) 0644 record=bytes.from_int(perms,2) 2) a common case of interactive use is to display a bytes string as a character string in order to spot which parts are text. In this case you ignore non-ASCII characters, and replace everything that cannot be printed with a space (as some hex editors do). So you don't need to care about encodings. import string def printable(c): ... if not c in string.printable: return ' ' ... if c.isspace(): return ' ' ... return c ... class bytes(list): ... def printable_ascii(self): ... return u.join([printable(chr(i)) for i in nb]) ... nb=bytes([48,0,10,12,34,65,66]) print nb.printable_ascii() 0 AB by the way, what will chr return in py3k ? Cheers, BC ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bytes thoughts
Baptiste Carvello wrote: while manipulating binary data will happen mostly with bytes objects, some operations are better done with ints, like the bit manipulations with the |~^ operators. Why not just support bitwise operations directly on the bytes object? -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
