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? 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. Regards, Martin
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