This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author theller
Recipients Alexander.Belopolsky, belopolsky, bob.ippolito, fredrik_j, mark.dickinson, pitrou, rhettinger, theller
Date 2010-03-05.19:17:52
SpamBayes Score 2.6922908e-14
Marked as misclassified No
Message-id <4B9158DC.1000606@ctypes.org>
In-reply-to <d38f5331003041845x78579b23q1b2ee463636679b1@mail.gmail.com>
Content
>> 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.
History
Date User Action Args
2010-03-05 19:17:55thellersetrecipients: + theller, rhettinger, bob.ippolito, mark.dickinson, belopolsky, pitrou, fredrik_j, Alexander.Belopolsky
2010-03-05 19:17:54thellerlinkissue887237 messages
2010-03-05 19:17:52thellercreate