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: Fred Wright
Subject: Re: [gpsd-dev] Update on Python Version Compatibility
Date: Mon, 28 Mar 2016 17:16:15 -0700 (PDT)

On Sun, 27 Mar 2016, Eric S. Raymond wrote:

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

I think it actually worked until the changes for Python 3, though I never
tested it.  But it's certainly pointless now - I'll take it out.

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

My original impression was that it's relevant even to top-level programs,
but upon rereading the doc, I guess not.  But I don't see it in gps/,
either.  This isn't about making it work, it's about setting it up so that
any future change that accidentally relies on implicit relative imports
fails the same way in Python 2 as it does in Python 3.

All those "future imports" are for things that couldn't be unconditionally
backported for compatibility reasons, but code that's fixed for Python 3
might as well enable the backports for more consistent behavior, whether
necessary or not.

Though I do wish one could have something like a .pdbrc containing a
statement like "from __past__ import print_statement". :-)

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

I've done a first pass on 'packet', based on the info in the page I
linked, but it still doesn't work, so I'll need to investigate further.

BTW, the concept of a "target Python" is needed to be able to build C
extensions for Python 3, since they need to build with the right include
files for Python 3, and simply getting the 'INCLUDEPY' config_var from the
scons Python (guaranteed to be Python 2 for the time being) doesn't cut
it.  For testing I just kludged in something to patch the value, but it
will need something better to work for real.

This also means that the regression tests will *have* to use the target
Python when targeting Python 3, unless there were a more elaborate scheme
to provide multiple versions of the extensions.  I.e., gpsfake won't work
with Python 2 if the packet module is built (only) for Python 3.

Fred Wright



reply via email to

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