[Python-Dev] adding Construct to the standard library?

[tomer filiba]

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 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?
>
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 str_to_ctype 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 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20060418/d0115426/attachment.htm