[Python-Dev] proposed struct module format code addition

[Carlos Ribeiro]

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