If someone's knowledge of Python is so shallow that they can't handle tuple unpacking, they should learn more Python. It's one of the basic foundations of the language, and it's hardly a difficult concept.
It is a good thing if code is readable by people who only know the language a little, only know similar languages, or have not used the language for years.
It is a good thing, but it isn't the highest good. It doesn't make sense to avoid useful basic features simply because they aren't immediately obvious to a novice in the language.
> If someone's knowledge of Python is so shallow that they can't handle tuple unpacking
Did you know that "tuple unpacking" actually works on arbitrary iterables (in fact, the relevant function in Python's C code is called ``unpack_iterable``)?
Yes. Why is that surprising? f is a generator, generators are iterables, iterables can be unpacked. I've always thought that the tuple referred to by 'tuple unpacking' was the target containing the variables being assigned, rather than the thing being unpacked, because you frequently unpack things other than tuples.
Your comment is interesting at a number of levels. And by interesting, I mean that I can hardly fathom you wrote it:
> Yes. Why is that surprising?
because you called it "tuple unpacking". Furthermore, because in functional languages where this feature comes from you actually unpack tuples, and pattern-matching of other structures is not called "tuple unpacking".
> I've always thought that the tuple referred to by 'tuple unpacking' was the target containing the variables being assigned
That's what the "tuple" is unpacked into, it makes no sense that the name of the pattern would come from there. At best and stretching it, you'd have "into-a-tuple unpacking". Furthermore, you're not actually unpacking into a tuple (even less so in Python 3, `(1, * a)` isn't a valid expression... anywhere that I know of), you're unpacking into free variables. That's the point of unpacking.
> because you frequently unpack things other than tuples.
The only other thing frequently unpacked is a list, and Python's tuples are immutable lists, it does not stretch the imagination that a read-only feature of tuples would work on their mutable cousin as well. As for other structures, in 6 years of Python I'd say I've seen unpacking of arbitrary iterators thrice at best. You do not frequently unpack dicts or iterators.
edit: fucking hell, yc's comment format sucks donkey balls.
> Your comment is interesting at a number of levels. And by interesting, I mean that I can hardly fathom you wrote it
I imagine a great many people will be "interested" in your response, then.
And really, you choose to be uncivil over a name? Arguing about names is one thing; insulting your opponent because he uses a different name than you do is just childish.
Anyway, since I can't seem to resist trollbait:
> because you called it "tuple unpacking".
It surprises you that historical terminology persists even a decade after limitations have been removed?
> Furthermore, because in functional languages where this feature comes from
Algol 60 had this feature under the name of "multiple assignment" I'll bet long before LISP had "destructuring-bind". This feature did not originate in functional languages.
> That's what the "tuple" is unpacked into, it makes no sense that the name of the pattern would come from there.
Prior to Python 1.5, the expression being unpacked had to be a tuple; now it does not. The name is derived from the original functionality. If you'd spent your effort referring to the Python Language Reference instead of telling the world how you can't fathom someone would use a different name than you would for this sort of assignment, you'd know this :)
> The only other thing frequently unpacked is a list, and Python's tuples are immutable lists
Unpacking applies to iterables. That seems obvious and easy, but the feature is commonly called "tuple unpacking" in the Python world despite the fact that more than tuples can be unpacked. I resolve the apparent conflict by thinking of the term as referring to the most common form of the literal on the left side of the statement, the same syntax as a tuple. If that's not the actual origin, fine, you win the pissing match. But where the name came from has zero bearing on the actual behavior of the language feature, and the point remains that the language feature is simple, consistent, and basic enough that if you don't understand it when you see it, you need to learn the language better.
The only other thing frequently unpacked is a list
Which isn't a tuple. You're the one trying to be pedantic, but you want to ding me for making this distinction?
it does not stretch the imagination that a read-only feature of tuples would work on their mutable cousin as well.
I agree, it doesn't. I don't see how it stretches the imagination that it works on general iterables, either.
Because packing multiple values on the right hand side always creates a tuple, and because the most common use of the feature – multiple assignment – deals with tuples, the “sequence unpacking” feature of Python is often called “tuple unpacking” instead, even by people who understand that any sequence can be unpacked.
"There should be one-- and preferably only one --obvious way to do it."
A couple of things:
1) The key word is obvious. There are oftentimes less obvious ways to do things that may be better for whatever reason.
2) It's not really reasonable to expect that there can only be one way to do everything.
What it really means is that (for instance) Python only allows one way to denote where a code block begins and ends (via indentation) while Ruby allows you to use curly brackets and begin/end. Nor does it have an unless statement that is equivalent to "if not"
This is the one way to do it. masklinn has cousin comment that does a good job of explaining why: http://news.ycombinator.com/item?id=1732575, and others have made some good points questioning whether you'd ever actually want to do this particular "it" in the first place.
