My take on this:
struct.pack/struct.unpack is already one of my least-favourite parts
of the stdlib. Of the modules I use regularly, I pretty much only ever
have to go back and re-read the struct (and re) documentation because
they just won't fit in my brain. Adding additional complexity to them
seems like a net loss to me.
I'd _love_ to find the time to write a sane replacement for struct - as
well as the current use case, I'd also like it to handle things like
attribute-length-value 3-tuples nicely (where you get a fixed field
which identifies the attribute, a fixed field which specifies the value
length, and a value of 'length' bytes). Almost all sane network protocols
(i.e. those written before the plague of pointy brackets) use this in
some way.
I'd much rather specify the format as something like a tuple of values -
(INT, UINT, INT, STRING) (where INT &c are objects defined in the
struct module). This also then allows users to specify their own formats
if they have a particular need for something.
Anthony
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
_______________________________________________
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
