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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4