[Python-3000] PEP 3124 - more commentary

[Phillip J. Eby]

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.

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

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.

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.