Changes by Ezio Melotti ezio.melo...@gmail.com:
--
versions: +Python 3.4 -Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue887237
___
___
Changes by Bruno Dupuis bdup...@lisael.org:
--
nosy: +bruno.dupuis
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue887237
___
___
Python-bugs-list
Changes by Daniel Urban urban.dani...@gmail.com:
--
nosy: +durban
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue887237
___
___
Python-bugs-list
Benjamin Peterson benja...@python.org added the comment:
You could write a Python script to generator the methods.
--
nosy: +benjamin.peterson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue887237
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
As far as I understand, the main concern about issue887237.diff was code
duplication. There are two ways to fight it: C preprocessor tricks as in
issue887237-macro.diff and code generation as done in numpy. With
Mark Lawrence breamore...@yahoo.co.uk added the comment:
Perhaps people could review the latest patch in view of the following.
1) Quote from Mark Dickinson msg75815
I think this would be valuable for rapid prototyping
of an algorithm in Python before translating it into
C. In particular, it
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
--
assignee: - belopolsky
components: +Extension Modules, ctypes -Library (Lib)
nosy: -Alexander.Belopolsky
stage: - patch review
versions: +Python 3.2
___
Python tracker
Thomas Heller thel...@ctypes.org added the comment:
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
Alexander Belopolsky alexander.belopol...@gmail.com added the comment:
Attaching a patch that is equivalent toissue887237.diff, but uses preprocessor
to generate repetitive code.
--
Added file: http://bugs.python.org/file16466/issue887237-macro.diff
Antoine Pitrou pit...@free.fr added the comment:
Le Fri, 05 Mar 2010 02:21:30 +,
Alexander Belopolsky rep...@bugs.python.org a écrit :
Code duplication is unavoidable because the goal is to give access to
machine arithmetics which means (# types) x (# operations) of very
similar looking
Alexander Belopolsky alexander.belopol...@gmail.com added the comment:
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
Changes by Alexander Belopolsky [EMAIL PROTECTED]:
Added file: http://bugs.python.org/file12323/ctypes-numbermixins-1.patch
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue887237
___
Thomas Heller [EMAIL PROTECTED] added the comment:
One difficulty with the patch is that the original ctypes code
contained a tp_as_number ...
This can be solved by changing the order of bases for c_type classes.
See attached.
Cool! Why didn't I think of that myself?
Thomas Heller [EMAIL PROTECTED] added the comment:
I wonder if a patch for ctypes like this (which is not yet complete)
could be used to implement this, or MUST it be implemented in C?
The patch contains a mixin class that implements the numeric methods.
However, the actual operation takes
Mark Dickinson [EMAIL PROTECTED] added the comment:
Is it be feasible to add arithmetic operations
to the ctypes integer types? Since ctypes is now
in the core, it would seem better to enhance ctypes
than provide a new module.
I think this would be valuable for rapid prototyping
of an
15 matches
Mail list logo
