Thoughts about Python

[Terry Reedy]

"Matthias" <no at spam.pls> wrote in message
news:36wu11g8ums.fsf at goya03.ti.uni-mannheim.de...
> Duncan Booth <me at privacy.net> writes:
> > The advantage of min and max as builtins are that they work on any
> > sequence. In particular they work on iterators. Having functions that
apply
> > to an arbitrary sequence avoids a lot of potential code duplication.
>
> Do you mean code duplication on the user side?  Or code duplication in
> Python's implementations?

Python's generic programming saves user code.

Write a function taking an iterable argument and it can be used with any of
the countable infinity of possible iterable types, current and future.  For
free, without having to subclass or otherwise attach the function as a
method to each.

Write an iterable type and it can be fed to any of the countable infinity
of possible sequence functions, written and yet to be written.  For free,
without adding them all as methods, which is impossible anyway for future
functions.

>  In the latter case,

But it is both cases, so your consequent does not follow.

> To me, Python's builtins are by far not a "problem", but I admit that
> I never understood why astring.len() doesn't work.

Because there is currently no process to make generic functions accessible
(aliased) as specific methods.  Possible (but not-serious) proposal:  Add
interface objects with attribute __takes__ being a set of functions which
takes objects implementing that interface as a single argument.  Give types
a set of interfaces called __implements__.   If attribute look-up fails,
search __takes__ for interfaces in __implements__.   But you now you have
to explicitly register objects with the sets, and you still have problems
with interfaces (virtual types) often being too narrow, too broad, and/or
too numerous and what to do with multiparameter functions.  Isn't
len(astring) easier, as well as one char shorter?

Terry J. Reedy