[GRASS-dev] [GRASS GIS] #2708: Run GRASS with Python3

[GRASS GIS]

#2708: Run GRASS with Python3
--------------------------+-------------------------
  Reporter:  zarch        |      Owner:  grass-dev@…
      Type:  defect       |     Status:  new
  Priority:  normal       |  Milestone:  7.0.4
 Component:  Default      |    Version:  unspecified
Resolution:               |   Keywords:
       CPU:  Unspecified  |   Platform:  Unspecified
--------------------------+-------------------------

Comment (by zarch):

 Dear Glynn,

 Replying to [comment:7 glynn]:
 > Replying to [comment:6 zarch]:
 >
 > > Testing with the python debugger:
 > >
 > {{{
 > ipdb> (1024 / (8 * sizeof(c_ulong)))
 > 16.0
 > 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:
 >
 > lib/python/ctypes/ctypesgencore/parser/cgrammar.py:282
 > {{{
 > -    '/': ("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
 generated files.
 >
 > 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
 division).
 >
 > 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.

 I was thinking to another option:

 Can we modify fix.sed, to not only fix the import but also substitute the
 line:

 {{{
     ('__val', c_ulong * (1024 / (8 * sizeof(c_ulong)))),
 }}}

 into:

 {{{
     ('__val', c_ulong * (1024 // (8 * sizeof(c_ulong)))),
 }}}

 What do you think?

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2708#comment:12>
GRASS GIS <https://grass.osgeo.org>