Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Python Programming

Open-Source Python Code Shows Lowest Defect Density 187

cold fjord sends news that a study by Coverity has found open-source Python code to contain a lower defect density than any other language. "The 2012 Scan Report found an average defect density of .69 for open source software projects that leverage the Coverity Scan service, as compared to the accepted industry standard defect density for good quality software of 1.0. Python's defect density of .005 significantly surpasses this standard, and introduces a new level of quality for open source software. To date, the Coverity Scan service has analyzed nearly 400,000 lines of Python code and identified 996 new defects — 860 of which have been fixed by the Python community."
This discussion has been archived. No new comments can be posted.

Open-Source Python Code Shows Lowest Defect Density

Comments Filter:
  • Re: Python == LAME (Score:5, Informative)

    by Anonymous Coward on Tuesday September 03, 2013 @05:27PM (#44751031)

    Most of Python isn't written in Python, smart ass. They're talking about the language interpreter itself, written in C/C++ etc.

  • Where is the study? (Score:2, Informative)

    by achacha ( 139424 ) on Tuesday September 03, 2013 @05:28PM (#44751039) Homepage

    I could not find a link to the actual study, instead the company links lead back to the article and the article leads back to the company home page. Is this more "faith-based computing"? I am interested in the comparisons to other languages and in what type of code was analyzed.

  • Hmmm (Score:5, Informative)

    by Anonymous Coward on Tuesday September 03, 2013 @05:32PM (#44751075)

    TFA seems to be about the Python interpreter, also known as CPython (because it's implemented in C), rather than about code written in Python itself. So maybe it has nothing to do with the Python language, but everything to do with the fact that the Python authors are apparently awesome C programmers.

    That's great, but most people interpret "Open Source Python Code" to mean code written in Python that is Open Source, not code written in C (to implement the Python interpreter) that is Open Source.

  • The Slashdot summary is confusing, as is the headline. Reading the article, it is clear that it is about the code that powers the official Python interpreter, AKA CPython, AKA /usr/bin/python. When I clicked the link, I thought Coverity had surveyed the entire world of open source Python code and discovered that Python programmers as a whole publish higher quality code than people who e.g. program in Ruby. That's not what the article's about.

    It'd be great if the headline in Slashdot were to be fixed to say, "Python interpreter has fewer code defects compared to other open source C programs, says Coverity."

  • Math impairment (Score:5, Informative)

    by fava ( 513118 ) on Tuesday September 03, 2013 @05:36PM (#44751113)

    0.005 defects per thousand lines times 400,000 lines gives a total defect count of 2.

    So where did the other 994 defects come from?

  • by dwheeler ( 321049 ) on Tuesday September 03, 2013 @05:39PM (#44751137) Homepage Journal

    Coverity sells software that does static analysis on source code and looks for patterns that suggest defects. E.G., a code sequence that allocates memory, followed later by something that de-allocates that memory, followed later by something that de-allocates the same memory again (a double-free).

    The product is not open source software, but a number of open source software projects use it to scan their software to find defects: [] It's a win-win, in the sense that Coverity gets reports from real users using it on real code, as well as press for their product. The open source software projects get reports on potential defects before users have to suffer with them.

  • by greg1104 ( 461138 ) <> on Tuesday September 03, 2013 @05:40PM (#44751147) Homepage

    Coverity's services have been useful to a number of open-source projects. But this article is carefully picking its terms to get a headline worthy result. Compare against the Coverity scan of PostgreSQL [] done in 2005 for example, and CPython's defect rate isn't very exciting at all. But that was "Coverity Prevent" and this is "Coverity Scan"...whatever that means.

  • by Krishnoid ( 984597 ) * on Tuesday September 03, 2013 @05:41PM (#44751165) Journal
    Here's the python dev's own page [] describing it and how to get to the results.
  • by MetalliQaZ ( 539913 ) on Tuesday September 03, 2013 @05:54PM (#44751271)

    The result in question tested the Python project's code, which is commonly known as CPython, which is the Python interpreter written in C.

  • by Anonymous Coward on Tuesday September 03, 2013 @06:04PM (#44751337)

    you should try TSAN. See :

  • Re:Can't be right (Score:4, Informative)

    by XcepticZP ( 1331217 ) on Tuesday September 03, 2013 @06:41PM (#44751569)

    it might have an advantage in forcing lazy programmers with no concept of 'code etiquette' to write semi-readable code as indentation is forced by syntax.

    on the other hand, making indentation part of the language creates all sorts of other readability problems.

    You'd be surprised at how much syntax in python actively ignores whitespace. As soon as you open up any brackets, it's a veritable free-for-all when it comes to whitespace and indentation. In such a scenario, a proper coding standard document is imperative for readable code.

  • Re:Math impairment (Score:5, Informative)

    by ShanghaiBill ( 739463 ) on Tuesday September 03, 2013 @09:06PM (#44752449)

    Does it analyze source code or is it like a fuzz tester?

    It is static analysis of source code. It doesn't actually run the code, it scans it for patterns that might be bugs. I like Gimpel Lint [] better, but it isn't either-or, so you can use both and they will find different bugs. You still need to do dynamic testing with something like Valgrind []. Tools are cheap compared to people, so you want to give your developers the best testing tools you can, and put your code through the wringer. We use six different tools for C/C++, and no code is shipped out the door till it passes them all (plus unit, usability, and requirements testing).

Solutions are obvious if one only has the optical power to observe them over the horizon. -- K.A. Arsdall