Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python idiom for taking the single item from a list

blog.garlicsim.org

Post reply on HN
Print view View original

31–40 of 97 posts

Re: Python idiom for taking the single item from a list

#31

Post by jerf »

alrex021 wrote: post #21

There you have it folks, Python supports destructuring assignment. :-)

What's the smiley for?

    Python 2.6.5...
    Type "help", "copyright", "credits" or "license" for more information.
    >>> (a, (b, c, (d, e))) = (1, (2, 3, (4, 5)))
    >>> a, b, c, d, e
    (1, 2, 3, 4, 5)
    >>> (a, (b, c, (d, e))) = (1, (2, 3, (4, 5, 6)))
    Traceback (most recent call last):
      File "", line 1, in 
    ValueError: too many values to unpack
It isn't quite as flexible as functional languages and it's not as idiomatic as it is in functional languages, but it's not a hack or quirky edge-case either.

Re: Python idiom for taking the single item from a list

#32

Post by digitallogic »

statictype wrote: post #6

So we have so if I was wrong in my original assumption that stuff has exactly one element, Python will shout at me before this will manifest itself as a hard-to-find bug someplace else in the program. and then later on, This method works even when stuff is a set or any other kind of collection. stuff[0] wouldn’t work on a set because set doesn’t support access by index number. The second argument is basically in favo…

Depends on which is more important. If it's an egregious error for there to be more than one element then I'd prefer the unpacking solution. However if ordering is/was involved at some point a set would indicate a possible bug (since they're unordered) so I might lean towards indexing.

They are both decent ideas, not hard fast rules. Let your context be your guide.

Re: Python idiom for taking the single item from a list

#34

Post by jemfinch »

teilo wrote: post #2

Excellent. That one belongs in any Python style guide. Though technically it's not a style, it does lead to better readability, and reduces the propensity for unforseen consequences.

The reason it's not in the Python style guide is because it's a symptom of other problems in code. Lists are for holding multiple values of the same type. If you know that a list will always have one and only one value, it's not conceptually a list, it's some other type that's been encoded into a list for some reason, and you should fix that conceptual mismatch rather than papering over the issue with a style idiom.

Re: Python idiom for taking the single item from a list

#35

Post by cool-RR »

jemfinch wrote: post #33

The real solution is not to arbitrarily encode your types as lists of exactly one item. If you find yourself passing around such lists with enough regularity that you feel the need to develop an idiom for deconstructing them, you're doing something wrong.

More often than not you are receiving a list from some function, not constructing it manually.

As an example: Say you have a GUI widget that can contain many entries, and you call `widget.get_entries()` which returns a list with all the entries. But if you know there must be only one entry, you can do `(entry,) = widget.get_entries()`.

Re: Python idiom for taking the single item from a list

#39

Post by jacobolus »

masklinn wrote: post #29
jfager wrote: post #20

Earlier quoted context omitted.

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 't…

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.

Re: Python idiom for taking the single item from a list

#40

Post by jemfinch »

masklinn wrote: post #29
jfager wrote: post #20

Earlier quoted context omitted.

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 't…

> 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

Python's tuples are not immutable lists. See http://mail.python.org/pipermail/python-dev/2003-March/03396... for Guido's own words saying it.

> edit: fucking hell, yc's comment format sucks donkey balls.

You could have saved yourself a lot of trouble and others (like myself) a lot of annoyance by simply not commenting.

Post reply on HN