Giovanni Bajo:<br>> Both ctypes and construct provide a way to describe a<br>> binary-packed structure in Python terms: and this is an overload of<br>> functionality<br>so does struct, so why not just use struct? there's a receipe at the python
<br>cookbook that adds "naming ability" to fields, i.e.<br><br>">6s.destincation 6s.source H.type"<br><br>something like that, so when you parse you get named attributes instead of<br>a tuple. so why did ctypes wrote another mechanism? because you can't extend
<br>it and you can't nest it. but ctypes, just as well, provides the mechanisms for its <br>requirements -- defining C structs, not arbitrarily complex structures. so of course<br>it doesnt, and shouldnt, support variable-length fields or data pointers, which are
<br>common in file formats, protocols, and other complex data structures -- what<br>you can't do with a C struct you don't need to do with ctypes.<br><br>----<br><br>now i'll save me a mail and put this also here:<br><br>
Greg Ewing:<br><pre>> It does seem rather silly to have about 3 or 4<br>> different incompatible ways to do almost exactly<br>> the same thing (struct, ctypes, NumPy and now<br>> Construct).</pre>* struct is designed for packing and unpacking, but is very limited
<br>* ctypes is not oriented at packing/unpacking, it only provided a<br>mechanism to handle its requirements, which are domain specific<br>and not general purpose.<br>* i never checked how NumPy packs arrays, etc., but it's also
<br>domain-specific, as it's a math library, not a generic packer/unpacker.<br><br>and trust me those are not the only ones. the reason people have <br>to *reinvent the wheel* every time is the lack of a *generic* parsing/building
<br>library. (i prefer the term parsing over unpacking. check my blog for more<br>details)<br><br>yes, putting bytes together isn't too complicated, and because people<br>don't have a built-in mechanism for that, they tend to just "oh, well,
<br>it can't be too complicated, i'll just write one for me", and this yields many<br>flavors of packers/unpackers, all incompatible.<br><br>Construct is the first library, that i'm aware of, that is dedicated to<br>
parsing/building, instead of doing it as a side-kick domain-specific<br>mechanism.<br><br>Construct is a *superset* of all those packers and unpackers, and<br>had it been part of stdlib, people would have used it instead.
<br><br>of course it's only been released a month ago, and couldnt have been <br>already included in the stdlib, i still think it has a room there. existing <br>projects can be ported without too much effort, and new ones could
<br>benefit from it as well.<br><br><br>-tomer<br><br><br><div><span class="gmail_quote">On 4/19/06, <b class="gmail_sendername">Giovanni Bajo</b> <<a href="mailto:rasky@develer.com">rasky@develer.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">tomer filiba <<a href="mailto:tomerfiliba@gmail.com">tomerfiliba@gmail.com</a>> wrote:
<br><br>> the point is -- ctypes can define C types. not the TCP/IP stack.<br>> Construct can do both. it's a superset of ctype's typing mechanism.<br>> but of course both have the right to *coexist* --<br>> ctypes is oriented at interop with dlls, and provides the mechanisms
<br>> needed for that.<br>> Construst is about data structures of all sorts and kinds.<br>><br>> ctypes is a very helpful library as a builtin, and so is Construct.<br>> the two don't compete on a spot in the stdlib.
<br><br><br>I don't agree. Both ctypes and construct provide a way to describe a<br>binary-packed structure in Python terms: and this is an overload of<br>functionality. When I first saw Construct, the thing that crossed my head was:
<br>"hey, yet another syntax to describe a binary-packed structure in Python".<br>ctypes uses its description to interoperate with native libraries, while<br>Construct uses its to interoperate with binary protocols. I didn't see a good
<br>reason why you shouldn't extend ctypes so to provide features that it is<br>currently missing. It looks like it could be easily extended to do so.<br><br>Giovanni Bajo<br><br></blockquote></div><br>