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 thein ctypes, the endianness of numbers is determined by the platform, since
endianness of types like c_short - 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?
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 asorry, but if you mean people must use memmove in order to parse string,
structure definition - hence my str_to_ctype function. But that's a
trivial helper function to write, so that's not a big issue.
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.
on a spot in the stdlib.
-tomer
On 4/18/06, Paul Moore <[EMAIL PROTECTED]
> wrote:
On 4/17/06, tomer filiba <[EMAIL PROTECTED]> 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 str_to_ctype(s, typ):
... t = typ()
... memmove(addressof(t), s, sizeof(t))
... return t
...
>>> class ethernet_header(Structure):
... _fields_ = [("destination", c_char * 6),
... ("source", c_char * 6),
... ("type", c_short)]
...
>>> s = "ABCDEF123456\x08\x00"
>>> e = str_to_ctype(s, ethernet_header)
>>> 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 c_short - 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 str_to_ctype 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.
_______________________________________________ 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
