Python 3.2 has some deadly infection

Steven D'Aprano steve+comp.lang.python at pearwood.info
Sat May 31 22:26:17 EDT 2014


On Sat, 31 May 2014 17:10:20 +0100, Mark Lawrence wrote:

> Some interesting comments here
> http://techtonik.rainforce.org/2014/05/python-32-has-some-deadly-
infection.html
> so I'm simply asking for other opinions.

Oh, Anatoly Techtonik. He's quite notorious on python-dev for wanting to 
impose his wild and sometimes wacky processes on the entire community. 
Specific examples aren't coming to mind, and I'm too lazy to search the 
archives, so I'll just make one up to give you an idea of the flavour of 
his requests:

    "Twitter is the only way that developers can effectively
    communicate. We must shut down all the mailing lists and the
    bug tracker and move all communication immediately to 
    Twitter. And by we I mean you."
    [Not an actual quote.]

I've come to the conclusion that he occasionally has a point to his 
posts, but only at random by virtue of the scatter-gun technique. He's 
obviously widely read, but not deeply, and so he fires off a lot of ill-
thought out but superficially attractive proposals. Just by chance a few 
of them end up being interesting, not *interesting enough* for somebody 
else to do the work. At this point the ideas languish, because he refuses 
to sign a contributor agreement so the Python core developers cannot 
accept anything from him.

This blog post is a strong opinion about Python, but it isn't clear what 
that opinion *actually is*. His post is rambling and unfocused and 
incoherent ("art is the future"). He rails against having to write PEPs, 
and decries the lack of stats, summaries, analysis and comparison, 
utterly missing the point that the purpose of the PEP process is to 
provide those stats, summaries, analysis and comparison. Reading between 
the lines, I think what he means, deep down, is that *somebody else* 
ought to gather those stats and do the analysis to support his ideas, and 
not expect him to write the PEP.

He makes at least one factually wrong claim:

    "I thought that C/C++ must die, because really all major 
    security problems are because of it."
    [actual quote]

He's talking about buffer overflows. Buffer overflows have never been 
responsible for "all" major security problems. Even allowing for a little 
hyperbole, buffer overflows have not been responsible for the majority of 
major security problems for a very long time. It is not 1992 any more, 
and today the single largest source of security bugs are code injection 
attacks. In Python terms that mostly means failure to sanitize SQL 
queries and the use of eval() and exec() on untrusted data.

http://cwe.mitre.org/top25/

Three of the top four software errors are forms of code injection: SQL 
injection, OS command injection, cross-site scripting. The classic C 
buffer overflow comes in at number 3, so it's not an inconsiderable cause 
of security vulnerabilities even today, but it is not even close to the 
only such cause.

See also http://www.sans.org/top25-software-errors/ 

Back to the blog post... it's 2014, Python 3.3 and 3.4 have come out, why 
is he talking about 3.2?

It's interesting that he starts off by stating his graph is meaningless:

    "They don't measure anything - just show some lines that 
    correlate to each other."

then immediately tries to draw a conclusion from those lines:

    "It looks like the peak of Python was on February 2011, 
    and since then there was a significant drop."

I've written about the difficulty of measuring language popularity in any 
meaningful way:

http://import-that.dreamwidth.org/1388.html
http://import-that.dreamwidth.org/2873.html

Anatoly has picked the TIOBE Index, but I don't know that this is the 
best measure of language popularity. According to it, Python is more 
popular than Javascript. I love Python, but really, more popular than 
Javascript? That feels wrong to me.

In any case, I think that a better explanation for the observed dip in 
Feb 2011 is not that Python 3.2 is infected (infected by what?) but 
*regression to the mean*. Regression to the mean is a statistical 
phenomenon which basically says that all else being equal, an extreme 
value is likely to be followed by a less extreme (closer to the average) 
value.

Language popularity, as measured by TIOBE, is at least in part random. 
(Look at how wiggly the lines are. The wiggles represent random 
variation.) If by chance a language gets a spike in interest one month, 
it is less likely to 

Because TIOBE's results contain so much random noise, they really ought 
to smooth them out by averaging the scores over a three month window, and 
show trend lines. They don't, I believe, because random hiccoughs in the 
data provide interest: "Last month, Java was overthrown from it's #1 
ranking by C. This month it has fought its way back to #1 again! Tune in 
next month to see if C can repeat it's stunning victory!!!"

I think that long term trend lines would be much less exciting but much 
more informative. Eyeballing the graph, it seems to me that Java and C++ 
are trending down, C is probably steady, and Objective C and Python 
trending up. If by chance there was a flurry of interest in Python for a 
month or two, and then things fell back to normal (regression to the 
mean), that might look like a slump.

But I digress... back to Anatoly's post. I think he reveals more about 
himself than Python:

    "When these little things sum up, you realize that you're 
    just wasting time trying to improve things that people 
    don't want to improve. They don't want to improve the process.
    They don't realize that the problem is not in the language, 
    but in the way they don't want to hear each other. Technology
    showed that people want to be heard, that they opinion should
    be  accounted  , not closed as  won't fix  , or  works for 
    me  . It is not a community process, when you rely on abilities
    of certain individuals to monitor and respond to all traffic
    and wishes, especially when they fail to do so."

On Python-Dev, this is Anatoly's repeated claim: the process is broken, 
because well it just is okay. In my opinion, "the process is broken" is 
Anatoly's shorthand for "I want to do things THIS way, and you won't let 
me. My way is SO OBVIOUSLY BRILLIANT that everybody, no matter their 
circumstances, will be immeasurably better off by switching to my process 
instead of the old way of doing things. Anyone who thinks differently is 
simply not paying attention. Didn't you hear how brilliant my process is?"

Anatoly does make a few concrete complaints about Python 3, or at least 
as concrete as he gets in this post:

"I expected Python 3 to be ready for the internet age" -- What does that 
mean? What makes him think it isn't?

"with cross-platform behavior preferred over system-dependent one" -- 
It's not clear how cross-platform behaviour has anything to do with the 
Internet age. Python has preferred cross-platform behaviour forever, 
except for those features and modules which are explicitly intended to be 
interfaces to system-dependent features. (E.g. a lot of functions in the 
os module are thin wrappers around OS features. Hence the name of the 
module.)

"with clear semantics to work with binary data" -- There are clear 
semantics to work with binary data: use bytes, and the struct module. 
Those features can be improved, and indeed Python 3.4 has improved them, 
and 3.5 is in the process of improving them further. But to suggest that 
Python doesn't have those clear semantics is simply false.

"with non-confusing error handling" -- How is Python 3's error handling 
confusing? It's the same error handling as Python 2. Where is the 
confusion?


TL;DR: Anatoly's blog post is long on disappointment and short on actual 
content. It feels to me that we could summarise his post as:

    I don't know what I want, I won't recognise it even if I saw
    it, but Python 3 isn't it. I blame others for not living up
    to my expectations for features I cannot describe and were 
    never promised.



-- 
Steven



More information about the Python-list mailing list