On 5/14/07, Phillip J. Eby <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
