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

61–70 of 97 posts

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

#61

Post by durin42 »

jemfinch wrote: post #58
j_baker wrote: post #47

Personally, I think this is a bit on the "clever" side. Plus, the error message you get isn't as easy to understand as if you used an assert statement. I'd probably just do something like this: def get_single(l): assert l and len(l) == 1 return l[0] Then you get the best of both worlds: readability and a concise one-liner.

> assert l and len(l) == 1 This is redundant: if a list's length is 1, then it's true in a boolean context. Also, please stop naming your lists 'l'. On a vast array of fonts, it differs only in a few pixels from '1'. Use "L" instead :)

He's defending against None with the assert l and len(l) bit, or at least that's what I'd assume.

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

#62

Post by iron_ball »

njharman wrote: post #55
jemfinch wrote: post #34

Earlier quoted context omitted.

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.

Lists use (not infrequently) logic like the following; If one element do this one element thing else do this more than one element thing

But in that case, either your code is evidently in a branch where the list will have one item -- as in your example -- in which case the context makes it clear. And if there's no context, such as in a nested function call, then at some point you should be passing that lone list item into a function which takes the item as an argument.

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

#63

Post by iron_ball »

jfager wrote: post #53
TorKlingberg wrote: post #51

Earlier quoted context omitted.

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.

This is the argument I always have about the ternary syntax in C-like languages.

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

#64

Post by cool-RR »

jemfinch wrote: post #59
cool-RR wrote: post #49

Earlier quoted context omitted.

I'd avoid doing this, because people who'll read your code would have to check themselves what the `get_single` function does. Also, the performance here is probably much worse. (Although in many cases it would not matter.) But that's just my opinion, your suggestion is legitimate.

> I'd avoid doing this, because people who'll read your code would have to check themselves what the `get_single` function does. This is an argument against using functions at all. If it works against get_single, it works against all functions. That is to say, it doesn't work at all.

Yes, but with most functions there's no choice, because most of the functions in your program do something (a) complex and/or (b) specific to your program. This `get_single` function falls into neither of these categories.

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

#65

Post by j_baker »

jemfinch wrote: post #58
j_baker wrote: post #47

Personally, I think this is a bit on the "clever" side. Plus, the error message you get isn't as easy to understand as if you used an assert statement. I'd probably just do something like this: def get_single(l): assert l and len(l) == 1 return l[0] Then you get the best of both worlds: readability and a concise one-liner.

> assert l and len(l) == 1 This is redundant: if a list's length is 1, then it's true in a boolean context. Also, please stop naming your lists 'l'. On a vast array of fonts, it differs only in a few pixels from '1'. Use "L" instead :)

I wouldn't name a list l in real code. It was just the first thing that popped to mind. :-)

And as was mentioned the "assert l" part is defending against l being None. I suppose I could be more explicit by saying "assert l is not None and len(l) == 1".

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

#66

Post by _cbsz »

durin42 wrote: post #61
jemfinch wrote: post #58

Earlier quoted context omitted.

> assert l and len(l) == 1 This is redundant: if a list's length is 1, then it's true in a boolean context. Also, please stop naming your lists 'l'. On a vast array of fonts, it differs only in a few pixels from '1'. Use "L" instead :)

He's defending against None with the assert l and len(l) bit, or at least that's what I'd assume.

If he's defending against None, he should

    assert l is not None and len(l) == 1

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

#67

Post by viraptor »

orangecat wrote: post #54
j_baker wrote: post #47

Personally, I think this is a bit on the "clever" side. Plus, the error message you get isn't as easy to understand as if you used an assert statement. I'd probably just do something like this: def get_single(l): assert l and len(l) == 1 return l[0] Then you get the best of both worlds: readability and a concise one-liner.

That fails for sets and other non-list iterables. It would have to be something like: def get_single(l): i = iter(l) val = i.next() try: i.next() # expected to throw exception for one-element iterable except StopIteration: return val raise AssertionError('More than one object') Eww.

You don't need to do that for a set. sets support `len()`. Also set supports `pop()`, so the code is very similar to the list one:

    assert s and len(s)==1
    return s.pop()
Or if you want to stay in the immutable land:

    assert s and len(s)==1
    return tuple(s)[0]

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

#68

Post by _cbsz »

xiongchiamiov wrote: post #60
jemfinch wrote: post #57

Earlier quoted context omitted.

No doubt! But since we're on the subject of "how to make code like this better" it seems appropriate to discuss what's really wrong with the code, rather than just what sort of duct tape style guidelines we can use to patch over its flaws :)

Very often we can't change the API (standard library or such). Should we not change our code to address the issue as best we can?

This is Python. Subclass it and fix the problem, unless the guts are so opaque that your code would be littered with subclasses and you can't figure out an elegant, general way of fixing it (unlikely).

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

#69

Post by jemfinch »

cool-RR wrote: post #64
jemfinch wrote: post #59

Earlier quoted context omitted.

> I'd avoid doing this, because people who'll read your code would have to check themselves what the `get_single` function does. This is an argument against using functions at all. If it works against get_single, it works against all functions. That is to say, it doesn't work at all.

Yes, but with most functions there's no choice, because most of the functions in your program do something (a) complex and/or (b) specific to your program. This `get_single` function falls into neither of these categories.

Functions should not be complex. Functions should be simple, and they should be composed by other simple functions to do more complex things.

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

#70

Post by jemfinch »

j_baker wrote: post #65
jemfinch wrote: post #58

Earlier quoted context omitted.

> assert l and len(l) == 1 This is redundant: if a list's length is 1, then it's true in a boolean context. Also, please stop naming your lists 'l'. On a vast array of fonts, it differs only in a few pixels from '1'. Use "L" instead :)

I wouldn't name a list l in real code. It was just the first thing that popped to mind. :-) And as was mentioned the "assert l" part is defending against l being None. I suppose I could be more explicit by saying "assert l is not None and len(l) == 1".

Yes, you should definitely should be more explicit if that's what you intend to check: PEP8 makes that explicit.

I'm not sure why you'd defend against None anyway. Why defend against None, but not against 3.1459 or 4j or ''?

Post reply on HN