[GRASS-dev] [GRASS GIS] #2708: Run GRASS with Python3
trac at osgeo.org
Fri Jul 24 06:57:55 PDT 2015
#2708: Run GRASS with Python3
Reporter: zarch | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.1
Component: Default | Version: unspecified
Resolution: | Keywords:
CPU: Unspecified | Platform: Unspecified
Comment (by glynn):
Replying to [comment:6 zarch]:
> Testing with the python debugger:
ipdb> (1024 / (8 * sizeof(c_ulong)))
ipdb> c_ulong * (1024 / (8 * sizeof(c_ulong)))
*** TypeError: can't multiply sequence by non-int of type 'float'
> Do you have an idea on how we can fix this?
One option is to make ctypesgen use truncating division:
- '/': ("division", (lambda x,y: x/y), "(%s / %s)"),
+ '/': ("division", (lambda x,y: x/y), "(%s // %s)"),
However, this would break macros which perform floating-point division.
Another option would be to explicitly convert array sizes to integers, but
that still doesn't handle the situation where a macro is expecting "/" to
match C's division semantics (truncating division for integers, non-
truncating division for floating-point values).
Ultimately, ctypesgen just translates macros directly to Python, so
whichever division operator is used would be wrong for one case or the
other. We could change it to use e.g. c_division(a,b) and define that
function in ctypes_preamble.py. But that seems like overkill given that
(on Linux) there are two occurrences of the division operator in the
One of them is for the definition of sigset_t, which is required for
jmp_buf which in turn is required for G_fatal_longjmp(), and I'm not sure
it's even possible to make use of that from Python. The other is for a
macro named FUDGE() in ogsf.h, which I suspect is probably not
particularly useful (and that one happens to be a floating-point
An alternative option is to just guard the <setjmp.h> include and the
G_fatal_longjmp() declaration in defs/gis.h with `#ifndef CTYPESGEN`, and
do likewise for the FUDGE() macro in ogsf.h.
However, that ignores the possibility that other platforms may have macros
involving division in their system headers, or that future changes to
GRASS may pull in additional headers with such macros.
Yet another option is a combination of the other two: prevent ctypesgen
from ever seeing a macro involving division, and just remove the division
case from mult_ops_dict so that if it does encounter one it raises an
exception. That may require ongoing maintenance but avoids the situation
where we end up silently generating broken conversions of macros.
Ticket URL: <https://trac.osgeo.org/grass/ticket/2708#comment:7>
GRASS GIS <http://grass.osgeo.org>
More information about the grass-dev