gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eric S. Raymond
Subject: Re: [gpsd-dev] Update on Python Version Compatibility
Date: Sun, 27 Mar 2016 15:56:41 -0400
User-agent: Mutt/1.5.23 (2014-03-12)

Fred Wright <address@hidden>:
> 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.

Yes.  I should have removed the shim for 2.4 amd 2.5 some time ago.

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

That surprises me, but it's good.  So documented.

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

I've added future-division imports.

I think absolute imports is covered by the changes to gps/.  If it's not,
educate me - I may not have a complete grasp on the use cases.

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

I would, but I need to go work on ntpsec.

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

That'll work.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]