On 2009-01-25, Martin v. Löwis <mar...@v.loewis.de> wrote: > >>>> Take a look at the struct and ctypes modules. >>> struct is really not the choice. it returns an expanded string of the >>> data and this means larger latency over bluetooth. >> >> I don't know what you mean by "returns an expanded string of >> the data". >> >> I do know that struct does exactly what you requested. > > I disagree. He has a format (type, length, value), with the > value being variable-sized. How do you do that in the struct > module?
You construct a format string for the "value" portion based on the type/length header. >> It converts between Python objects and what is bascially a C >> "struct" where you specify the endianness of each field and >> what sort of packing/padding you want. > > Sure. However, in the specific case, there is really no C > struct that can reasonably represent the data. I don't see how that can be the case. There may not be a single C struct that can represent all frames, but for every frame you should be able to come up with a C struct that can represent that frame. > Hence you cannot really use the struct module. Perhaps I don't understand his requirements, but I use the struct module for protocols with type/len/value sorts of packets. >> I use the struct module frequenty to impliment binary, >> communications protocols in Python. I've used Python/struct >> with transport layers ranging from Ethernet (raw, TCP, and >> UDP) to async serial, to CAN. > > Do you use it for the fixed-size parts, or also for the > variable-sized data? Both. For varible size/format stuff you decode the first few bytes and use them to figure out what format/layout to use for the next chunk of data. It's pretty much the same thing you do in other languages. -- Grant -- http://mail.python.org/mailman/listinfo/python-list
