On Apr 8, 8:09 am, George Sakkis <george.sak...@gmail.com> wrote: > On Apr 7, 3:18 pm, Adam Olsen <rha...@gmail.com> wrote: > > > On Apr 6, 3:02 pm, George Sakkis <george.sak...@gmail.com> wrote: > > > > For example, it is common for a function f(x) to expect x to be simply > > > iterable, without caring of its exact type. Is it ok though for f to > > > return a list for some types/values of x, a tuple for others and a > > > generator for everything else (assuming it's documented), or it should > > > always return the most general (iterator in this example) ? > > > For list/tuple/iterable the correlation with the argument's type is > > purely superficial, *because* they're so compatible. Why should only > > tuples and lists get special behaviour? Why shouldn't every other > > argument type return a list as well? > > That's easy; because the result might be infinite. In which case you > may ask "why shouldn't every argument type return an iterator then", > and the reason is usually performance; if you already need to store > the whole result sequence (e.g. sorted()), why return just an iterator > to it and force the client to copy it to another list if he needs > anything more than iterating once over it ?
You've got two different use cases here. sorted() clearly cannot be infinite, so it might as well always return a list. Other functions that can be infinite should always return an iterator. > > A counter example is python 3.0's str/bytes functions. They're > > mutually incompatible and there's no default. > > As already mentioned, another example is filter() that tries to match > the input sequence type and falls back to list if it fails. That's fixed in 3.0. It's always an iterator now. > > > To take it further, what if f wants to return different types, > > > differing even in a duck-type sense? > > > > At a minimum it's highly undesirable. You lose a lot of readability/ > > maintainability. solve2/solve_ex is a little ugly, but that's less > > overall, so it's the better option. > > That's my feeling too, at least in a dynamic language. For a static > language that allows overloading, that should be a smaller (or perhaps > no) issue. Standard practices may encourage it in a static language, but it's still fairly confusing. Personally, I consider python's switch to a different operator for floor division (//) to be a major step forward over C-like languages. -- http://mail.python.org/mailman/listinfo/python-list
