Python 3 and 1.0

[Fred Wright]

On Tue, 26 Sep 2017, Eric S. Raymond via devel wrote:
> Ian Bruene via devel <devel at ntpsec.org>:
> >
> > The python 3 build appears to work. However it has a unicode bug in ntpq
> > (but not ntpmon! Yay consistency!), and I can not say that I *trust* any of
> > it.
> >
> > This is partially my fault, as I failed to test the software in Py3 as much
> > as I should have. As an excuse I will note that I fixed several py3 bugs in
> > the last few weeks, and part of the reason for the lack of testing has been
> > the higher friction in getting the p3 build to work.

I'd noticed the problem with "ntpq -p", and even made a brief attempt at
fixing it, but decided I needed to focus on the more pressing issues.

I also notcied that test_agentx.py doesn't work with Python 3, but my
impression is that the agentx stuff is still a WIP, anyway.

BTW, all the tests fail on FreeBSD, due to an undefined reference in
jigs.py.

On Tue, 26 Sep 2017, Eric S. Raymond via devel wrote:
> Ian Bruene via devel <devel at ntpsec.org>:
> > Post-1.0 I'd like to take a systematic look at how data is flowing through
> > the code and how it is being represented by the different versions of
> > python. I can't tell for sure yet what is and isn't a kluge. I know for
> > example that my fix earlier today was a band-aid due to time pressure and
> > not fully understanding the data flow. I do *not* like not knowing how many
> > of these there are.
>
> That's a good thing to be wary about.

Indeed.  When I started looking at the ntpq bug, I noticed that there
seemed to be some inconsistencies in whether 'response' was expected to be
str or bytes.  It doesn't matter in Python 2, of course.  But tossing in
enough polystr() and polybytes() calls to make the exceptions go away
isn't necessarily the best approach to making reliable code. :-)

Fred Wright