On Aug 25, 3:31 pm, "Hendrik van Rooyen" <[EMAIL PROTECTED]> wrote: > Actually, I am not complaining - I am asking for advice on the side > effects of what I am doing, which is replacing a bunch of bits > in what is essentially an output bit field with the corresponding > input bits at the same addresses read back from a simulated i/o > bus structure. And I would also like to know if there is a better > way of doing this.
Whenever I do low-level stuff like this, I'm in one of two modes: Mode #1: I'm using somebody else's C library and the overhead of doing so is small. Mode #2: I need to code my own low-level stuff (for speed, IO access, whatever). In mode 1, I try not to break out a compiler. ctypes is great for this, and the results are "pure python" to the extent that you can give pure python to someone else with the same C library, and it will work. No muss, no fuss, no makefile, no question that ctypes is awesome stuff. In mode 2, I have to break out a compiler. I almost never do this without ALSO breaking out Pyrex. Pyrex is also awesome stuff, and in Pyrex, you can easily create a (new) Python string for your results without having to worry about reference counting or any other really nasty low level interpreter details. You can code a lot of stuff in pure Pyrex, and you can easily mix and match Pyrex and C. Pyrex and ctypes are both tools which let me connect to non-Python code without having to remember to handle Python interpreter internals correctly. If I can get by with ctypes, I do, but if I actually have to code in something other than Python to get the job done, I bypass ctypes and go straight for Pyrex. -- http://mail.python.org/mailman/listinfo/python-list
