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

[massimo di stefano]

Hi,

is this the right ticket to look into the porting of grass to work with python3 ? 
what’s the state of port, is there any temporary fork of the project or should I apply the several patches on this ticket ?

At the moment my build fails on most of core modules  my default python is V3.
Is there a way to specify in the configure which python has to be used for to build grass ?

Thanks!

Massimo.


> On Jul 24, 2015, at 9:57 AM, GRASS GIS <trac at osgeo.org> wrote:
> 
> #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)))
> 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.
> 
> --
> Ticket URL: <https://trac.osgeo.org/grass/ticket/2708#comment:7>
> GRASS GIS <http://grass.osgeo.org>
> 
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev