On Sun, 03 Oct 2004 23:18:20 +0200, Martin v. Löwis <martin at v.loewis.de> wrote: > 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 at gmail.com mail: carribeiro at yahoo.com
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4