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