>> Code duplication is unavoidable because the goal is to give access to
>> machine arithmetics which means (# types) x (# operations) of very
>> similar looking functions. I considered reducing (perceived) code
>> duplication through some pre-processor magic, but doing so would make
>> code much harder to understand and almost impossible to debug.
> 
> Carefully written macros shouldn't be hard to understand.
> At least there wouldn't be the risk of overlooking one of the methods
> when making modifications.

The code duplication in Alex's patch is indeed enormous.  I can see
two solutions to avoid (or work around) them.  Use of macros, or writing
a Python script that generates the C-code.  Anyway, I guess his patch
is some example code, not more.  (Using C++ overloaded functions or even
templates would be another - but only theoretical - possibility).

> I would like to hear from Thomas before introducing macros in this
> code.  I tried to follow the style of cfield.c which shows similar
> code duplication.
> 
> There are also some questions that need to be answered before
> polishing the code.
> 
> 1. Should mixed arithmetics be supported?
> 2. Should we do anything special about floating point operations?
> Wrapping them in PyFPE_START/STOP_PROTECT?
> 3. Should we support in-place operations?
> 4. Bitwise operations on integers?

I would answer 1, 3, and 4, with 'yes'. However, this grows the code size
by another dimension since we now have #types * #operation * #types.

My answer for question 3 is 'I don't know'.

Before I forget:  It may be possible to implement ctypes number methods
as a third-party module by implementing a mixin class, and replacing the
c_... type definitions in Lib/ctypes/__init__.py.