On Fri, May 31, 2013 at 4:51 AM, Ian Kelly <ian.g.ke...@gmail.com> wrote: > On Thu, May 30, 2013 at 12:44 PM, Chris Angelico <ros...@gmail.com> wrote: >> On Fri, May 31, 2013 at 4:36 AM, Ian Kelly <ian.g.ke...@gmail.com> wrote: >>> I don't object to changing the join method (one of the more >>> shoe-horned string methods) back into a function, but to my eyes >>> you've got the arguments backward. It should be: >>> >>> def join(sep, iterable): return sep.join(iterable) >> >> Trouble is, it makes some sense either way. I often put the larger >> argument first - for instance, I would write 123412341324*5 rather >> than the other way around - and in this instance, it hardly seems as >> clear-cut as you imply. But the function can't be written to take them >> in either order, because strings are iterable too. (And functions that >> take args either way around aren't better than those that make a >> decision.) > > The reason I like having the shorter argument first (at least for > function calls) is for when I'm reading the code. If I'm interested > in the second argument, then to find it I have to scan over the first > argument. I would rather scan over something short like '\n' than > something longer like a list comprehension. It sounds like a trivial > thing, but it really does make it easier to find where an expression > starts and ends when the expression is short.
Yes, I do agree with that argument. But there's more to picking argument order than simply "sort by predicted length" :) I'm not saying it's *wrong* to put sep first, just that it's not as clearly-and-obviously-the-one-right-way as you suggested. ChrisA -- http://mail.python.org/mailman/listinfo/python-list