[Python-3000] PEP 3124 - more commentary

[Guido van Rossum]

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/)