I just ran
python -Qwarn -tt -3
on a custom python script and the first line returned is
gis.py:801: DeprecationWarning: classic int division
Is this something that needs to be fixed?
Nikos
I just ran
python -Qwarn -tt -3
on a custom python script and the first line returned is
gis.py:801: DeprecationWarning: classic int division
Is this something that needs to be fixed?
Nikos
On Sat, May 2, 2015 at 8:13 AM, Nikos Alexandris <nik@nikosalexandris.net>
wrote:
I just ran
python -Qwarn -tt -3
on a custom python script and the first line returned is
gis.py:801: DeprecationWarning: classic int division
Is this something that needs to be fixed?
in Python 2 :
1 / 2
results in 0, that's 'classic int division'
in Python 3 it results in 0.5
so it warns you that you are using 'classic int division' so in Python 3
this will change result. So depending on what you want, either use
float(1)/2
or to keep the integer division
from __future__ import division
1//2
Nikos
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Nikos Alexandris wrote:
I just ran
python -Qwarn -tt -3
on a custom python script and the first line returned is
gis.py:801: DeprecationWarning: classic int division
Is this something that needs to be fixed?
That specific warning relates to code which is generated by ctypesgen
from system headers. Specifically, the definition of __sigset_t in
<sigset.h>:
# define _SIGSET_NWORDS (1024 / (8 * sizeof (unsigned long int)))
typedef struct
{
unsigned long int __val[_SIGSET_NWORDS];
} __sigset_t;
is translated to:
# /usr/include/bits/sigset.h: 30
class struct_anon_11(Structure):
pass
struct_anon_11.__slots__ = [
'__val',
]
struct_anon_11._fields_ = [
('__val', c_ulong * (1024 / (8 * sizeof(c_ulong)))),
]
__sigset_t = struct_anon_11 # /usr/include/bits/sigset.h: 30
The reason this is ending up in gis.py is for the definition of
jmp_buf which is used by G_fatal_longjmp().
As that function is (probably) unusable from Python, we could probably
just guard the declaration with "#ifndef CTYPESGEN".
But that may not be the only such issue.
For compatibility with Python 3, we need to add
from __future__ import division
and use "//" for integer (truncating) division. But IIRC, that
requires Python 2.7. If GRASS still works with 2.6, it's not worth
abandonding support for it over this issue, given that there are
almost certainly far more significant issues with Python 3
compatibility (such as its insistence on coercing everything to
Unicode).
--
Glynn Clements <glynn@gclements.plus.com>