source code size metric: Python and modern C++

[David Abrahams]

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

> |Lulu of the Lotus-Eaters <mertz at gnosis.cx> writes:
> |> Neither 'sequence' nor 'number' are Python 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.
>
> David Abrahams <dave at boost-consulting.com> wrote previously:
> |They're not concrete types. However, in "computer language developer
> |lingo", they can be said to be types.
>
> Abrahams and I don't differ on the fact here, just the name.  

Not even that. I recognize the common usage. I just think it's useful
to have a perspective that includes the whole continuum for 'type'.

> So it is perhaps not of huge importance.

Right.

> But I think my use is more natural.  For example, what I am calling
> "type" is what the Python 'type()' function identifies, and what is
> imported from the 'types' module.  Moreover, this notion of type is very
> similar to the type declarations, type casts, etc. in a very large
> number of programming languages.
>
> The abstract notions "some kind of number" or "some kind of sequence"
> are typically harder to pin down in -any- programming language.
> Actually, a good word for them is "kind", in opposition to "type."

Kind is a fine word. So is Concept. A rose by any other name...

> |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,
>
> I partially agree here.  I don't think Python can or should "nail down"
> what a sequence is.  

In that case, we should stop using phrases like "s must be a sequence"
in documentation.

> I use lots of sequence like things when I write Python, and they are
> not all the same as each other.  Different ones support different
> operations, and any formal list that says "a sequence must do X, Y,
> Z" will exclude some of my perfectly useful sequence-like objects.
> Either that, or it will be so general as to trivially include almost
> everything.

It's nice to be able to call both of these a sequence, even though
they have nothing in common...

    class X:
        def __getitem__(self, i):
            if i >= 10: raise IndexError
            return i

    class Y:
        def __len__(self):
            return 3

However, telling your users that your function requires a sequence
argument is now quite useless to them, isn't it?

> But I wouldn't mind if there was some kind of canonical list of
> "sequence like" options.  Function/module creator could include a little
> chart of what their tool needs.  If the format was standard, it would be
> easier to read quickly.  E.g.:
>
>     Length:     Req
>     Indexing:   Req
>     Slice:      N/A
>     iadd        N/A
>     ...

It's not enough. You need to specify semantics (say what these things
do) in addition valid expressions (which operations are
supported). __iadd__ for lists is very different from __iadd__ for
numbers. 

Does writing all of that down each time you write a function accepting
a sequence argument sound tedious to you?  It does to me. That's why
we need some nice formally-defined terms like "sequence"** which fully
describe common, useful Concepts (for lack of a better word).

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.

-Dave

**okay, use "tartemption" if you really hate the idea of nailing down
the meaning of "sequence"

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