andrew cooke wrote: > George Sakkis wrote: >> That's more of a general API design question but I'd like to get an >> idea if and how things are different in Python context. AFAIK it's >> generally considered bad form (or worse) for functions/methods to >> return values of different "type" depending on the number, type and/or >> values of the passed parameters. I'm using "type" loosely in a duck- >> typing sense, not necessarily as a concrete class and its descendants, >> although I'm not sure if even duck-typing is endorsed for return >> values (as opposed to input parameters). > [...] > > you probably want to look up substitutability: > http://www.google.cl/search?q=substitutability+principle
actually, this is better: http://www.google.cl/search?q=substitution+principle the idea being that if the "contract" for your function is that it returns a certain type, then any subclass should also be ok (alternatively, that subclasses should be written so that they can be returned when a caller was expecting the superclass) andrew -- http://mail.python.org/mailman/listinfo/python-list
