Re: [gpsd-dev] Update on Python Version Compatibility

[Eric S. Raymond]

Fred Wright <address@hidden>:
> 
> I did some more extensive testing of the six end-user Python programs
> against various versions of Python (on OSX).  This was all done from the
> build directory, so that library locations weren't an issue.
> 
> First of all, Python < 2.6 doesn't work for a variety of reasons.  And
> Python 3 < 3.3 doesn't work due to the lack of the Unicode literal.

These were expected.  I don't think we've been compatible back to 2.5
for some years.

> So the current maximal compatibility list is 2.6, 2.7, 3.3, 3.4, 3.5, and
> everything below is relative to that.
> 
> I was able to locally extend py-gobject3 (officially only 2.7, 3.4, and
> 3.5) to include 3.3, but not 2.6.  The latter case doesn't build even
> though the website claims 2.6 is adequate.
> 
> gegps:
> Works with all versions.
> 
> gpscat:
> Only works with Python 2, due to the 'packet' C module not working with
> Python 3.  However, to get it to work with 2.6, I needed to build my own
> Python 2.6 (a tweaked MacPorts version), since both the standard MacPorts
> version and the Apple version have select.poll disabled, for resons that
> appear to be historical.
> 
> gpsfake:
> Only works with Python 2, for the same 'packet' reason.  This may have
> been missed since "scons check" explicitly runs it with the scons Python.
> 
> gpsprof:
> Now works with all versions, but needed a minor fix for a preexisting
> (since Nov-2013) issue with Python 2.6.  Patch sent.
> 
> xgps:
> Only works with Python 2.7, as far as I can test.  I don't think it has
> any direct issues with Python 2.6, but I have no py-gobject3 for 2.6 as
> noted above.  It doesn't work with Python 3 due to the 'clienthelpers' C
> module not working.

This is all as I expected, once I became aware of the set-literal bug
in gpsprof.
 
> xgpsspeed:
> Only *fully* works with 2.7, as far as I can test.  As with xgps, I think
> it would probably work with 2.6 if there were a py-gobject3 for 2.6.  With
> Python 3, the main display works fine but the skyview overlay is missing.
> I didn't notice this before because the satellite view info is normally
> unavailable in my setup unless I take some special actions, which I hadn't
> done when I tested it before, and never having seen that display I didn't
> miss it. :-)

That is *weird*.

I saw this bug, and I fixed it at 2016-03-25T01:19:11, and I swear I saw
the damn sat display *work* under 3, but now I revert to the 'fixed' version
and it doesn't.  Hallucination?  Quantum indeterminacy?  I have no idea,
and that's worrisome.

A few minutes of digging revealed that in Python 3 something in the chain of
transmission from the daemon was returning an opaque 'map' object rather than a
satellite list.

I needed to do this:

--- a/gps/client.py
+++ b/gps/client.py
@@ -167,7 +167,7 @@ class gpsjson:
         # Should be done for any other array-valued subobjects, too.
         # This particular logic can fire on SKY or RTCM2 objects.
         if hasattr(self.data, "satellites"):
-            self.data.satellites = map(dictwrapper, self.data.satellites)
+            self.data.satellites = [dictwrapper(x) for x in 
self.data.satellites]

which isn't much less mysterious, because all I do with the map object in
xgpsspeed is iterate over it to get at the dictwrapper instances, and
you're supposed to be able to do that.

Fix pushed, but I still don't know why this detour was necessary.

> I believe the issues with packet and clienthelpers have to do with the
> fact that C code really needs some fixes to work with Python 3, as
> described here:
> 
>       http://python3porting.com/cextensions.html

Probably.  Have you got time to dig into this?  I'd do it, but I've
been neglecting ntpsec for the last couple days and need to get back to that.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>