COCOMO - appropriate for languages like Python?

[Skip Montanaro]

It's been many years since I've considered software cost estimation models
like COCOMO.  Is COCOMO appropriate to apply to high-level languages like
Python?  I believe COCOMO assumes each fully debugged source line of code
(SLOC) in any language and for any purpose costs roughly the same amount to
produce.  The cost savings for languages like Python would come because you
have to write so many fewer lines of code to implement the desired
functionality.

This constant cost per SLOC assumption seems at least marginally invalid to
me.  For example, writing an extension module which wraps a preexisting C
library is generally pretty straightforward (even without tools like SWIG or
Pyrex), but is pretty verbose, so COCOMO would tend to overestimate the cost
to produce such code.  It also seems the clarity of a language's constructs
will make a difference.  For example, in C I can write

    if ((c = gets(s)) == EOF) {
        ...
    }

while in Python, even though I have to express that concept in two lines:

    s = sys.stdin.readline()
    if s == "":
        ...

you can argue the Python code is less likely to contain a bug.  Together,
the cost to create those two (fully debugged) lines of Python code may well
be less than the cost to create the one line of C code, not twice the cost
of the one line of C code, as COCOMO would estimate it.

Are there other (more modern?) cost estimation models which don't assume
cost-wise that a SLOC is a SLOC is a SLOC?

-- 
Skip Montanaro
skip at pobox.com
consulting: http://manatee.mojam.com/~skip/resume.html