A lengthy and strongly opinionated post about Python features to the python-ideas mailing list garnered various responses there, from some agreement to strong disagreement to calling it "trolling", but it may also lead the Python community to better define what Python is. Trolling seems a somewhat unfair characterization, but Simon Lovell's "Python Reviewed" post did call out some of the fundamental attributes of the language and made some value judgments that were seen as either coming from ignorance of the language or simply as opinions that were stated as facts in a brusque way. The thread eventually led to the creation of a document meant to help head off this kind of thread in the future.

Good, bad, and ugly

Lovell's message started off with a short list of "The Good", but quickly moved into a list of "The Bad" that included more explanation of the features he disliked. It included entries for things he was unhappy with: the colons at the end of if , for , and similar statements (which he deemed unnecessary), the lack of an end statement for blocks (less readable), and no do-while loop. He also thought that the else clause for loops should have a different name (and suggested whenFalse ), that print() should not have been changed to a function in Python 3 ("adds no positive value that I can see"), etc. As might be guessed, he ended with an entry for "The Ugly". It complained about non-zero integer values being treated as "true" ("crapulence from C" that violates the "explicit is better than implicit" principle from PEP 20).

Some of the entries in the good and bad lists were either incorrect or misunderstandings of how to use Python, which put Lovell on the wrong foot with many python-ideas readers. But his tone also put some off. As Stephen D'Aprano put it: "As a newcomer to this community, and apparently the language as well, do you understand how obnoxious and arrogant it comes across for you to declare what is and isn't 'good' and 'bad' about the language [...]". He warned Lovell that the tone of his message might make responses "blunt or even brusque", but he did reply at some length.

For example, D'Aprano pointed him at the FAQ entry that explains the reasons behind the colons for if , et al. (readability, essentially). He also disagreed strongly with the need for an end statement, but agreed that else for loops was misnamed (though it is too late to change that now). Meanwhile, D'Aprano said that he preferred treating non-zero numbers as true values.

Chris Angelico also thought that the way Python does truth testing is both helpful and non-ugly:

In Python, *everything* is either true or false. Anything that represents "something" is true, and anything that represents "nothing" is false. An empty list is false, but a list with items in it is true.

D'Aprano and Angelico both agreed with the decision to change print() to a function. Angelico said that it "adds heaps of positive value to a lot of people", while D'Aprano was more specific about the advantages:

Consistency: print doesn't need to be a special cased statement. It does nothing special that a function can't do. So why make it a statement? As a function, it can be passed around as a first class value, used as a callback, monkey-patched or shadowed or mocked as needed. None of these things are possible with a statement.

Overall, the thread proceeded like most in Python mailing lists. Folks were generally helpful even when they were resolute about disagreeing with Lovell. On the other hand, Lovell didn't seem to quite pick up the vibe of the list. For example, responses like "I don't really see how that can be argued" or "I may be arrogant but I can't take it seriously" did not go over all that well.

Trolling?

Eventually, Guido van Rossum started a new thread entitled "How to respond to trolling". In it, he suggested that responding to Lovell's posts was counterproductive: "I think a much more effective response would have been a resounding silence." But several thought that was not entirely fair. Ned Batchelder said:

I don't like to use the term "trolling" except for people who are trying to annoy people. I think the recent thread was misguided, but not malicious. I do agree that the thread should have ended at "unless you are seriously proposing a change to the language, this is not the right list."

There were a number of suggestions in the original thread for Lovell to take the topic to a different mailing list (python-list, which is for more general Python discussions). Since Lovell wasn't really suggesting changes to the language (at least formally), some thought the discussion belonged on a different list. Though Nick Timkovich wasn't sure that even if Lovell had proposed the changes it would be a topic for python-ideas: "If you're proposing throwing half of Python's current syntax in the bin, this isn't the right list either."

However Van Rossum was adamant that the Lovell's post did not deserve a response:

Whether the intent was to annoy or just to provoke, the effect was dozens of messages with people falling over each other trying to engage the OP, who clearly was ignorant of most language design issues and uninterested in learning, and threw some insults in for good measure. The respondents should have known better.

But D'Aprano saw things differently. What Van Rossum had suggested was effectively "shunning" Lovell, which is "a particularly nasty form of passive-aggression, as the person being shunned doesn't even get any hint as to what they have done to bring it on". He also pointed out that it may not have been clear to Lovell that he was crossing a line, because it is an unwritten one:

Giving a newcomer the Silent Treatment because they've questioned some undocumented set of features not open to change is not Open, Considerate or Respectful (the CoC). Even if their ideas are ignorant or ill-thought out, we must give them the benefit of the doubt and assume they are making their comments in good faith rather than trolling.

Things that won't change

In an attempt to rectify the "undocumented" piece, D'Aprano proposed an informational PEP called "Things that won't change in Python". In it, he listed a number of things that are known to be immutable in Python, but that perhaps those outside the community are not aware of. The rationale, as described in the PEP, is to reduce noise on python-ideas and other lists by heading off suggestions that have no chance to be accepted "because the benefit is too little, the cost of changing the language (including backwards compatibility) is too high, or simply because it goes against the design preferred by the BDFL".

Some of the things listed in the PEP are fairly obvious (Python 3 will not be abandoned, there will be no Python 2.8), some were at least partly in response to Lovell's post (colons after if and the like, no end statement, print() will remain a function), and others came from recurring suggestions to the lists (no braces around blocks, significant indentation will remain, the >>> interactive prompt will stay as the default). Each entry comes with a bit of justification, often with links to a FAQ entry or other documentation.

In general the response was positive. There was naturally some wordsmithing (or bikeshedding) over the name and whether it should be a PEP or something else, but there was little disagreement over the listed choices—unsurprisingly. Van Rossum said that he had not followed the discussion closely, but that it made sense to delineate some unchangeable features of the language:

People who come in with enthusiastic proposals to fix some pet peeve usually don't have the experience needed to appreciate the difficulty in maintaining backwards compatibility. (A really weird disconnect from reality happens when this is mentioned in the same breath as "please fix the Python 2 vs. 3 problem". :-) I would also guess that for things that are actually controversial (meaning some people hate a feature that other people love), it's much easier to explain why it's too late to change than it is to provide an objective argument for why the status quo is better. Often the status quo is not better per se, it's just better because it's the status quo.

Lovell did reply to Van Rossum's "trolling" message, but was still on the offensive ("More than half of what I suggested could have and should be implemented."). He also continued to insist that Python's "truthiness" is ugly: "Calling truthiness of non boolean data 'Ugly' is an insult? It is ugly." Brett Cannon, who is one of the list administrators, tried one more time to explain why Lovell was not getting the response he was seemingly looking for:

It's this sort of attitude which puts people off. It is your opinion that it should be implemented, not a matter of fact as you have stated it. Just because something could be done doesn't mean it should be done. You're allowed to have your opinion, but stating it as anything but your opinion does not engender anyone to your opinion.

That led to a bit of a digression on the term "warts", which is sometimes used in the Python community to describe some missteps and misfeatures that exist in the language. It was mostly agreed that warts are "ugly" at some level, but it is a self-applied term, which makes it a bit more acceptable. And Van Rossum is not even sure they are missteps, exactly:

I believe that most of the warts are not even design missteps -- they are emergent misfeatures, meaning nobody could have predicted how things would work out.

In the end, the situation was handled pretty well, as is always the case in the Python community, it seems. One can imagine a much ruder response that a critical post like that might receive in other free-software communities. So far, it doesn't seem like the PEP has gone anywhere since it was discussed in mid-January, but the exercise and discussion were useful; if nothing else it can serve as a place to point the next person who comes along with "great ideas" that will never become a part of Python.

Comments (22 posted)

The failure of the Network Time Protocol (NTP) project could be catastrophic. However, what few have noticed is that the attempts to prevent that catastrophe may have created entirely new challenges.

NTP is a Internet Engineering Task Force (IETF) standard, handled by its NTP working group. As Tom Yates described it in an LWN article:

[NTP] quietly and without much fuss performs the critical Internet function of knowing the correct time. Using it, a computer with imperfect communications links may join a distributed community of servers, each of which is either directly attached to a reliable clock, or is trying to best synchronize its clock to one or more better-synchronized members of the community.

First designed in 1985 by David L. Mills, the protocol has been coordinated in recent years by the Network Time Foundation. Today, it develops a number of related standards, including Ntimed, PTPd, Linux PTPd, RADClock, and the General Timestamp API. For most of this time, the primary manager of the project has been Harlan Stenn, who has volunteered thousands of hours at the cost of his own consulting business while his NTP work is only intermittently funded.

Several years ago, the project's inadequate funding became known in the media and Stenn received partial funding from the Linux Foundation's Core Infrastructure Initiative, which was started after the discovery of how the minimal resources of the OpenSSL project left systems vulnerable to the Heartbleed vulnerability. Searching for additional funding, Stenn contacted the Internet Civil Engineering Institute (ICEI) and began working with two of its representatives, Eric S. Raymond and Susan Sons.

However, the collaboration did not go smoothly. According to Stenn, Raymond contributed one patch and had several others rejected, but Stenn's ideas and Raymond's and Sons's were out of sync. "I spent a lot of time trying to work with Susan Sons," Stenn said in a phone interview, "Then all of a sudden I heard they have this great plan to rescue NTP. I wasn't happy with their attitude and approach, because there's a difference between rescuing and offering assistance. [Their plan was] to rescue something, quote unquote, fix it up, and turn it over to a maintenance team." Beside the fact that this plan would eliminate Stenn's role, he considered it impractical because the issue is not merely maintenance, but also continued development of the protocol. The efforts to collaborate finally collapsed when Raymond and Sons created a fork they called Network Time Protocol Secure (NTPsec).

Today, the NTP Foundation lists four main contributors, one of whom is on sabbatical and acknowledges the contributions of 33 in all. In addition, another seven work on related projects. By contrast, NTPsec lists seven contributors, including Sons. Although NTPsec began by using the NTP code, today neither NTP nor NTPsec shares code or patches with the other.

Both projects would probably more or less agree on the general outline of events given above. Yet it is difficult to be sure, since both Sons and Mark Atwood, NTPsec's Project Manager pro-tem, ignored requests for an interview. However, the details of the two project's claims could hardly be farther apart. The two projects differ on the scale and cause of NTP's current problems and the approach that should be taken to address those problems.

The NTPsec version

Sons has publicly described the NTPsec interpretation several times, including in a presentation at OSCON and in a podcast interview with Mac Slocum of O'Reilly. In the podcast, Sons depicted NTP as a faltering project run by out-of-touch developers. According to Sons, the build system was on one server whose root password had been lost. Moreover, "the standard of the code was over sixteen years out of date in terms of C coding standards" and could not be fully assessed by modern tools. "We couldn't even guarantee reproducible results across different systems," she added.

Sons also claimed that "security patches weren't being circulated in a timely manner," taking "months to years" for release. Meanwhile, "security patches were being circulated secretly and leaked," although she did not explain how. Instead she offered an anecdote about a group of script-kiddies who knew that NTP was useful for denial of service attacks while remaining unaware of its function.

However, Sons was most concerned about the aging group of developers who maintain low-level Internet software (including NTP) in general. Most of them, she said, "are older than my father.... [and] are not always up to date on the latest techniques and security issues." Many are burning out from trying to maintain critical code while working full time jobs, and Sons suggested that they "should be retired."

Faced with such chaos, Sons said, she soon realized that "the Internet is going to fall down if I don't fix this." When efforts to gain acceptance for her plans from Stenn and other NTP developers failed, Sons and Raymond started NTPsec, placing the revised code in a Git repository rather than the Bitkeeper one used by the NTP Foundation, rewriting NTP rewriting NTP scripts in Python rather than C various other languages to make attracting new developers easier, and actively promoting the project in order to attract volunteers.

In her OSCON presentation she listed several accomplishments (Sons refers to the original NTP project as "NTP Classic"):

Due to a reduction in code of over 2/3 (from 227kLOC to 74kLOC), NTPsec was immune to over 50% of NTP Classic vulns BEFORE discovery in the last year.

NTPsec patches security vulnerabilities, on average, within less than 12 hours after discovery. Note that publication is sometimes slowed to coordinate with NTP Classic releases.

NTPsec's vulnerability response has pressured NTP Classic to speed up their response from months-to-years to days-to-weeks upon threats of funders pulling out.

[...] NTPsec is poised to replace NTP Classic in the coming year in installations around the world.

Sons's perspective on her involvement is summarized by the title of her OSCON presentation: "Saving Time." She has since become president of ICEI; she described herself in the presentation as having "moved on" and is no longer involved with NTPsec on a daily basis.

Meanwhile, a web search shows that media coverage of events accepts Sons's account while rarely attempting to hear NTP's side of the story. Cory Doctorow repeated the NTPsec version, and so did Brady Dale of the Observer, while Steven J. Vaughan-Nichols recommended NTPsec over NTP. The security site UpGuard was equally unquestioning, while CircleID, a site specializing in Internet infrastructure, only revised its coverage after complaints from representatives of NTP. In public, the NTPsec version of events has become the official one.

The NTP side

NTPsec depicted NTP as being in a state of total disorder. However, in communications with me, Stenn offered a radically different story. In Stenn's version of events, NTPsec, far from being the savior of the Internet, has misplaced priorities and its contributors lack the necessary experience to develop the protocol and keep it secure.

Stenn denied many of Sons's statements outright. For example, asked about Sons's story about losing the root password, he dismissed it as "a complete fabrication." Similarly, in response to her remarks about older tools and reproducible results across different systems, Stenn responded: "We build on many dozens of different versions of different operating systems, on a wide variety of hardware architectures [...] If there was a significant problem, why hasn't somebody reported it to us?"

Asked about how current the code is, Stenn stated that "the code has been and continues to be written to compile and run on currently available and currently used systems." Stenn conceded that some code only builds on older machines, yet pointed out that many old machines are still running. "If hardware is still in use, from our point of view there is an actual benefit to doing what we can to make sure folks can build the latest code on older machines."

As for security patches, Stenn acknowledged that NTP currently lacks the funding for a much-needed replacement of Autokey, the code that authenticates NTP servers. However, he noted that NTP released five major patches in 2016, and claimed that it was up to date as of the end of November 2016. He added, "I have no idea what she's talking about [in regard to] secret circulation of patches or leaked patches."

Moreover, Stenn questioned the accomplishments listed in Sons's presentation. In particular, the reduction of NTPsec's code base, even allowing for the relative compactness of code written in Python, becomes less impressive in light of Stenn's explanation that NTP is "the only reference implementation for NTP, and that means we have to provide complete functionality." Stenn claimed that NTPsec has "removed lots of stuff that has zero reported bugs in them, like sntp, the ntpsnmd code, and various refclocks." Although a less than complete implementation might have its uses, Stenn claimed that NTPsec has gone too far in removing code, and that its bug repairs have sometimes been at the cost of reduced functionality.

In general, Stenn wondered if, after only a couple of years work, NTPsec contributors have the experience necessary to work with the code. His own understanding of the protocol has changed several times during his decades of work, and he warned that "if you don't understand how everything works and where it fits into place, when things get busy, horrible things can happen." The NTPsec story frequently spoke of free-software ideals such as openness, transparency, and a welcoming environment to all contributors, "but this isn't a democratic process. It's a scientific process, and this isn't somebody's turn to go ahead and take theirs at the wheel driving the bus."

Still, the NTPsec fork has caused some changes in the NTP project. After NTPsec began, the foundation felt the need to commission regular financial audits, and to continue code audits that were begun in 2006.

"Creative destruction ('let's see what happens if we throw something into the works') is a horrible way to provide core Internet structure," Stenn concluded.

One step forward, two steps back?

For outsiders, which version of events is closer to the truth is difficult to assess. Probably few are competent to judge. However, assigning blame is beside the point.

What is of concern is that acceptance of the two implementations of the NTP protocol has been based largely on the most appealing story, and not on the quality of the code. NTPsec's constant analogy to the need to support OpenSSL evokes an immediate concerned response from free-software supporters, but, if Stenn is correct in his assertions, the situations of NTP and OpenSSL are not usefully comparable.

In particular, having two separate projects may be no more than a duplication of effort. Although having competing projects can sometimes benefit free software, in this case, having two warring projects risks diluting the already limited resources and support being contributed to put the protocol on a reliable footing.

Despite all the efforts of both projects, the possibility remains that the dangers to the protocol are as great today as they were before anyone attempted to address them. Already, where once only Stenn was looking for support, now Raymond is in a somewhat similar position, as NTPsec has lost its Core Infrastructure Initiative funding as of September 2016. It is all too easy to imagine the struggle for survival growing worse for everyone.

[Update: As noted in the comments, it was the scripts that were rewritten in Python for NTPsec.]

Comments (89 posted)