source code size metric: Python and modern C++

[David Abrahams]

Lulu of the Lotus-Eaters <mertz at gnosis.cx> writes:

> Duncan Grisby <duncan-news at grisby.org> wrote previously:
> |the Python documentation _does_ explicitly mention argument types.
>
> The examples chosen actually generally contradict the assertion.
>
> |join(seq)
> |    Return a string which is the concatenation of the strings in the
> |    sequence seq.
>      ^^^^^^^^^^^^
> |utime(path, times)
> |    Set the access and modified times of the file specified by path.
> |    If times is None, then the file's access and modified times are
> |    set to the current time. Otherwise, times must be a 2-tuple of
> |    numbers
>      ^^^^^^^
> Neither 'sequence' nor 'number' are Python types.  

They're not concrete types. However, in "computer language developer
lingo", they can be said to be types.

> List are types, as are tuples, as are ints, longs, floats.  But
> 'sequence' and 'number' are more like schematic references to "some
> type that behaves enough like we need it to."  In fact, custom
> sequences (or custom numbers) word fine too.

Sort of, and only sometimes. One of the biggest problems facing Python
IMO is that documentation doesn't really tell you what you can count
on. How much of the sequence protocol do these things need to satisfy?
How much of the number protocol? Suppose I pass complex numbers, which
don't allow the use of relational operators like <,<=, et. al?

> Mind you, I don't think the Python documentation *should* specify type
> explicitly.  The "quacks like a duck" philosophy is one of the powerful
> features of Python.

I have absolutely _no problem_ with "duck typing" (I heard the
inventor of Ruby use this term last month), as long as you say
reasonably precisely what it means to be a duck. That means that you
have to say not only which expressions are valid, but what their
semantics are.

Alex Stepanov established this practice for generic programming in C++
when he started writing down "Concepts"
(http://www.boost.org/more/generic_programming.html#concept) for the
STL. I've been trying to convince Guido that it's important to nail
down what we mean by "sequence" (and the rest of 'em) for some time
now, especially in light of the fact that the Python documentation
strongly implies in several places that such a definition exists (see
http://www.python.org/doc/current/api/abstract.html). So far, I guess
I've been unsuccessful!

It just isn't sufficient to say "if the code doesn't like what you
pass it, it will throw an exception at you, so don't worry". There are
lots of reasons. For example:

1. Potentially important program or external state may have been
   unrecoverably modified by that point.

2. I might not be able uncover all of the code's requirements in
   testing. Suppose it only calls my sequence's __len__ function in
   one relatively obscure code path (perhaps while processing another
   error)?

-- 
                       David Abrahams
   dave at boost-consulting.com * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution