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

[Fred Wright]

On Sun, 27 Mar 2016, Eric S. Raymond wrote:
> 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.

Actually, the doc claims compatibility back to 2.4, provided that you have
simplejson in the 2.4/2.5 case, and there's even still fallback code in
client.py for that (which should really be removed now).  The gpsprof bug
was presumably just an oversight.

Since I was trying to put all the compatibility info in one place, I
wanted to list the expectations explicitly, whether surprising or not.
Also, there was some question about whether 3 compatibility broke 2.6
compatibility, and it appears that it doesn't (beyond the py-gobject3
availability).

The errors one gets when trying 2.5 vary, mainly because the "future
import" stuff seems to use just what's necessary for the specific program,
though it seems to me it would be better to use all three items (including
absolute imports) in all cases, just to minimize behavioral differences
between Python 2 and Python 3, particularly in future changes.  E.g., if
someone writes "/" when they mean "//", it would be desirable for it to
misbehave under Python 2 the same way as it does under Python 3.

> This is all as I expected, once I became aware of the set-literal bug
> in gpsprof.

I expect so, though changing the shebang line in gpsfake was premature.
But changing it back now just to change it yet again once the library is
fixed probably isn't worthwhile.

> > 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.

Maybe the Tracker needs an "Observed POM Dependence" field. :-)

> 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.

Yeah, in Python 3, map() returns an iterator rather than a list.  2to3
warns you about that.  The usual simplest change is to wrap a list()
around the map(), though your fix works just as well.

BTW, I did test it and it works now.

> > 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.

Yeah, I could take a look at that.  I wasn't sure if you already were.

My inclination would be to take the conditionally-defined macro approach,
rather than plastering #ifs through the body of the code, and putting the
definitions in a new include file (python_compatibility.h?).

Fred Wright