[Python-Dev] deprecating string module?

[David Abrahams]

From: "Guido van Rossum" <guido@python.org>


> > > In python, you don't need overloading, you have a variety of
> > > optional parameter mechanisms
> >
> > ...which forces users to write centralized dispatching mechanism
> > that could be much more elegantly-handled by the language. The
> > language already does something just for operators, but the rules
> > are complicated and don't scale well.
>
> I don't think the situation can be improved without adding type
> declarations.

You could do a little without type declarations, to handle functions with
diffrent numbers of arguments or keywords, though I don't think that would
be very satisfying.

A good solution would not neccessarily need full type declaration
capability; just some way to annotate function signatures with types. What
I mean is that, for example, the ability to declare the type of a local
variable would not be of any use in overload resolution.

In fact, pure (sub)type comparison is probably not the best mechanism for
Python's overload resolution. For example, it should be possible to write a
function which will match any sequence object.

I'd like to see something like the following sketch:

1. Each function can have an optional associated rating function which,
given (args,kw) returns a float describing the quality of the match to its
arguments
2. When calling an overloaded function, the best match from the pool of
overloads is taken
3. The default rating function works as follows:

  a. Each formal argument has an optional associated match object
  b. The match object contributes a rating to the overall rating of the
function
  c. If the match object is a type T, the rating system favors arguments x
where T appears earlier in the mro of x.__class__. The availability of
explicit conversions such as int() and float() is considered, but always
produces a worse match than a subtype match.
  d. If the match object is a callable non-type, it's expected to produce
an argument match rating

Obviously, there are some details missing. I have to think about this stuff
anyway for Boost.Python (since its current trivial overload resolution is
not really adequate); if there's any interest here it would be nice for me,
since I'd stand a chance of doing something which is likely to be
consistent with whatever happens in Python.

-Dave