[Python-3000] PEP 3124 - more commentary (original) (raw)

Guido van Rossum guido at python.org
Tue May 15 02:51:19 CEST 2007

On 5/14/07, Phillip J. Eby <pje at telecommunity.com> wrote:

At 05:17 PM 5/14/2007 -0700, Guido van Rossum wrote: >Other use cases that come to mind are e.g. APIs that you can pass >either a Point object or two (or three!) floats. This is not a natural >use case for argument default values, and it's not always convenient >to require the user to pass a tuple of floats (perhaps the >three-floats API already existed and its signature cannot be changed >for compatibility reasons). Or think of a networking function that >takes either a "host:port" string or a host and port pair; thinking of >this as having a default port is also slightly awkward, as you don't >know what to do when passed a "host:port" string and a port.

How do people handle these in Python now? ISTM that idiomatic Python for these cases would either use tuples, or else different method names.

Both of which are sub-optimal compared to the C++ and Java solutions. (Especially for constructors, wheer choosing different method names is even moe effort as you'd need to switch to factory functions.)

Or is the intention here to make it easier for people porting code over from Java and C++?

No, my observation is that they have something that would be useful for us.

Anyway, as I said, I think it's possible to do this. It just strikes me as more complex than existing ways of handling it in Python.

More importantly, it seems to go against the grain of at least my mental concept of Python call signatures, in which arguments are inherently named (and can be passed using explicit names), with only rare exceptions like range(). In contrast, the languages that have this sort of positional thing only allow arguments to be specified by position, IIRC. That's what makes me uncomfortable with it.

Well, in my metnal model the argument names are just as often irrelevant as they are useful. I'd be taken aback if I saw this in someone's code: open(filename="/etc/passwd", mode="r"). Perhaps it's too bad that Python cannot express the notion of "these parameters are positional-only" except very clumsily.

That having been said, if you want it, there's probably a way to make it work. I just think we should try to preserve the "nameness" of arguments in the process -- and consider whether the use cases you've listed here actually improve the code clarity any.

There seems to be a stalemate. It seems I cannot convince you that this type of overloading is useful. And it seems you cannot explain to me why I need a framework for method combining.

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-3000 mailing list