ctypes, as the name implies, is relevant to *C data structures* only.<br>you cannot extend it and you cannot define complex things with it, at least not<br>easily.<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
* ctypes doesn't have a way (that I'm aware of) to specify the<br>endianness of types like c_short - so my example, when run on Windows<br>(intel architecture) gives type = 8, rather than type = 2048 (from the<br>wiki). But the wiki example doesn't explicitly specify endianness, so
<br>maybe that's a limitation in Construct as well?<br></blockquote>in ctypes, the endianness of numbers is determined by the platform, since<br>
they are passed to a C (platform-dependent) function. you share your address<br>space with the dll you load -- so both python and the dll live on the same platform.<br>so except of writing data to files or sockets, you shouldn't care about the byte
<br>ordering.<br><br>
in Construct you have UBInt16 and ULInt16, for big and little ordering. and UInt16 is <br>an alias to UBInt16 (because network ordering is more common in protocols)<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
* ctypes doesn't have an easy way to parse a string based on a<br>structure definition - hence my str_to_ctype function. But that's a<br>trivial helper function to write, so that's not a big issue.<br></blockquote>sorry, but if you mean people must use memmove in order to parse string,
<br>you better slap yourself. this is a python mailing list, not a C one. we don't <br>have a concept of addressof() or physically moving data. we use objects and<br>references. no offense, but "so that's not a big issue" makes me think you
<br>don't belong to this mailing list.<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">I'm not sure I understand the other wiki examples - but the ones I do,
<br>look doable in ctypes.</blockquote><div><br>i gues you should also look at <a href="http://pyconstruct.wikispaces.com/demos" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://pyconstruct.wikispaces.com/demos
</a> to get<br>a better understanding, but i only uploaded it a couple of hours ago. sorry for that. <br>anyway, on the projects page i explain thoroughly why there is room for yet another<br>parsing/building library.<br>
</div><br>but for the example you mentioned above, the ethernet header, struct is good enough:<br><br>struct.pack(">6s6sH", "123456", "ABCDEF", 0x0800)
<br><br>but --<br>how would you parse a pascal-string (length byte followed by data of that length)<br>using ctypes? how would you read a 61 bit, unaligned field? how would you convert <br>"\x00\x11P\x88kW" to "00-11-50-88-6B-57", the way people would like to see MAC
<br>addresses? <br><br>yeah, the MAC address is only a representation issue, but adapters can do much <br>more powerful things. plus, people usually prefer seeing "IP" instead of "0x0800" in <br>their parsed objects. how would you define mappings in ctypes?
<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">Personally, I'd rather see the ctypes facilities for structure packing<br>and unpacking be better documented, and enhanced if necessary, rather
<br>than having yet another way of doing the same thing added to the<br>stdlib.</blockquote><div><br>the stdlib is too messy already. it must be revised anyway, since it's full of shit<br>nobody uses. <br><br>the point is -- ctypes can define C types. not the TCP/IP stack. Construct can do both.
<br>
it's a superset of ctype's typing mechanism. but of course both have the right to *coexist* -- <br>
ctypes is oriented at interop with dlls, and provides the mechanisms needed for that. <br>
Construst is about data structures of all sorts and kinds. <br><br></div>ctypes is a very helpful library as a builtin, and so is Construct. the two don't compete<br>on a spot in the stdlib.<br><br><br><br>-tomer<br><br>
<div><span class="gmail_quote">On 4/18/06, <b class="gmail_sendername">Paul Moore</b> <<a href="mailto:p.f.moore@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">p.f.moore@gmail.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;">
On 4/17/06, tomer filiba <<a href="mailto:tomerfiliba@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">tomerfiliba@gmail.com</a>> wrote:<br>> after several people (several > 10) contacted me and said "IMHO 'construct'
<br>> is a good candidate for stdlib",
<br>> i thought i should give it a try. of course i'm not saying it should be<br>> included right now, but in 6 months time, or such a<br>> timeframe (aiming at python 2.6? some 2.5.x release?)<br><br>Now that ctypes is part of the standard library, that provides a
<br>structured datatype facility. Here's an example demonstrating the<br>first example from the Construct wiki:<br><br>>>> from ctypes import *<br><br>>>> def str_to_ctype(s, typ):<br>... t = typ()<br>
... memmove(addressof(t), s, sizeof(t))<br>... return t<br>...<br>>>> class ethernet_header(Structure):<br>... _fields_ = [("destination", c_char * 6),<br>... ("source", c_char * 6),
<br>... ("type", c_short)]<br>...<br>>>> s = "ABCDEF123456\x08\x00"<br>>>> e = str_to_ctype(s, ethernet_header)<br><br>>>> e.source<br>'123456'<br>>>>
e.destination
<br>'ABCDEF'<br>>>> e.type<br>8<br><br>I'm not sure I understand the other wiki examples - but the ones I do,<br>look doable in ctypes.<br><br>There are a couple of things to note:<br><br>* ctypes doesn't have a way (that I'm aware of) to specify the
<br>endianness of types like c_short - so my example, when run on Windows<br>(intel architecture) gives type = 8, rather than type = 2048 (from the<br>wiki). But the wiki example doesn't explicitly specify endianness, so
<br>
maybe that's a limitation in Construct as well?<br><br>* ctypes doesn't have an easy way to parse a string based on a<br>structure definition - hence my str_to_ctype function. But that's a<br>trivial helper function to write, so that's not a big issue.
<br><br>Personally, I'd rather see the ctypes facilities for structure packing<br>and unpacking be better documented, and enhanced if necessary, rather<br>than having yet another way of doing the same thing added to the<br>
stdlib.<br><br>Paul.<br></blockquote></div><br>