Python - hard to re-aquire

[Hal Murray]

> I'm pretty sure this is a problem with the ntpq code, not with Python -
> Python in general has a reputation for being *easy* to read six months later,
> which I think is deserved.  It's one of the first things I noticed when I
> started coding in Python back in 1998 or so. 

The hard to-go-back-to comment came from friends that I trust as much as I 
trust you. (I worked closely with them for ~10 years.)

I don't maintain a lot of python code.  I have a handful of python hacks.  The 
small ones are easy to maintain.  I find ntpq hard to work with.  As you 
suggest, that could be because it is crappy code.  It could also be because my 
head depends on type checking and python is full of automatic conversions that 
conflict with strong type checking.

It's possible that my friends got burned by something equivalent to ntpq being 
crappy code or as you suggest the code they were working on had too many cute 
chunks.

In my example with ntpq, it wasn't understanding the code that was the problem 
is was understanding how data got passed up/down the call stack.  My memory is 
that something was missing in the call/return parameters.

---------

>> There is a bug in our ntpq, or was not-that-long-ago and I'm pretty sure it 

> I'm aware.  Some time back I spent a day hunting for that bug.  I couldn't
> find it.  That's a nasty thicket of code in there. 

The bug is in the interface between the code that collects packets and checks 
the sequence numbers to make sure it got all the packets in the clump and the 
code up a few layers that decides how big the clump should be.  Tangled in 
there is that the collect-it code should return a partial clump but doesn't.

I'll track it down if you want to look again.  It may be in the issue already.

---------

Another thing to consider...

You are planning to convert everything to Go without changing the structure, 
then go back and clean things up.

Why didn't ntpq get cleaned up after it was moved to Python?

----------

[Go being easy to read.]
> BTW, I will not strongly assert that this is an advantage over Rust, because
> I never grokked Rust well enough to make a really fair comparison.  But Rust
> requires a lot of ceremony in the form of lifetime declarations that neither
> Python nor Go does; a priori this probably does put it at a readability
> disadvantage.

This should be an interesting experiment.  The same info that is a 
complication also tells you what is going on.



-- 
These are my opinions.  I hate spam.