source code size metric: Python and modern C++

[Laura Creighton]

David Abrahams

<snip>

> Otherwise, people will keep doing what they do today, which is either:
> 
> 1. Just specify that the function requires some concrete type, e.g. a
>    list or tuple. At least its possible to give clients a clear
>    specification of what's required of them.
> 
> 2. Write that it accepts any "sequence", and leave the client to read
>    the source or hope they chose the right set of sequencey operations
>    to implement.
> 
> Neither of thse leaves much hope for robust generic programming in
> Python.

What you are proposing is to make another type, so that people can know
what is required of them, when they are asked for that particular type.
This will cause trouble for those of us who are already using 'sequence'
to mean some subset or superset of whatever you come up with.  Our problem
of knowing whether we can use object X in protocol Y remains, we will
just have one fewer word to discribe our objects with.

My experience is that a lot of protocols that  'expect a sequence' want 
'any sliceable object' and that is all.

What I want is an arbitrary way, in the language or in an IDE, to ask
'can I use this object here' and why not if I cannot.  PEP 246, Object
Adaption  http://www.python.org/peps/pep-0246.html suggests one way we
might do this.

Laura Creighton