On Sun, 03 Oct 2004 23:18:20 +0200, Martin v. Löwis
Carlos Ribeiro wrote:
Sorry for introducing my not-very-qualified words on this topic, but... I've read the thread up to this point wondering why the bytes() type were not being thought of as a clean and definitive solution to this problem. It would allow to greatly simplify everything regarding struct, binascii and arbitrary low level data manipulation for networking and similar stuff.
No, it wouldn't. If you have a 'long' value, and you want to convert it to 'bytes', how exactly would you do that? Two's complement, I suppose - but that would close out people who want unsigned numbers. Also, do you want big-endian or little-endian? What about a minimum width, what about overflows?
Well, I don't intend to get way too off topic. But in my mind, it makes sense to have a few methods to allow any struct-type hack to work *directly* with the bytes() type. For example: the bytes() type could have a constructor that would take a struct-type string, as in: bytes(data, 'format-string-in-struct-format') or bytes.fromstruct(data, 'format-string-in-struct-format') Alternatively, an append method could take two parameters, one being the data to be appended, and the other the 'transformation rule' -- big endian, little endian, etc: bytes.append(data, 'format-string-in-struct-format') The interface for the data specification could also be a little bit cleaner; I don't see great value at specifying everything with single-character codes. It may look obvious to old C coders, but it doesn't mean that it's the only, or the better, way to do it. Besides concatenation, a few other transformations are useful for bytes -- shifting and rotation in both directions (working at bit level, perhaps?). That's how I thought it should work. (... and, as far as binascii is concerned, I see it more as a way to encode/decode binary data in true string formats than anything else.)
Tim has proposed a signature for binascii that covers all these scenarios, and I doubt it could get simpler then that and still useful.
I also agree with Tim Peters comments regarding struct's C heritage -- I never really liked C even when I *had* to use it daily, and the struct syntax still reads alien to me. I know this is another timeframe entirely, but *if* my vote counted, I would be +1 for a future struct implementation tightly integrated with the bytes() type.
I think you will find that the struct module *already* supports the bytes type. The bytes type will be just a synonym for the current string type, except that people will stop associating characters with the individual bytes; plus the bytes type will be possibly mutable. As the struct module creates (byte) strings today, it will trivially support the bytes type.
As I've explained above, it's a good first step, but a true bytes() type could have a little bit more functionality than char strings have. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: carribeiro@gmail.com mail: carribeiro@yahoo.com