[Python-ideas] get() method for list and tuples

Michel Desmoulin desmoulinmichel at gmail.com
Tue Feb 28 20:56:44 EST 2017


> 
> I am aware of that. I'm just saying you don't have to use try...except, 
> you can use slicing instead. Obviously you have to adapt the code since 
> you are getting a list not a single item:
> 
> # may fail, if alist is empty
> if alist[0] == "spam": ...
> 
> # cannot fail
> if alist[0:1] == ["spam"]: ...
> 
...
> 
> first_item = (alist[0:1] or ["ham"])[0]

Come on, I've been doing Python for more than a decade and never saw
anybody doing that. Even reading it in a code would make me scratch my
head for a moment with a "what is it doing that for?".

You are trying to hard to provide a counter argument here.

> 
> But honestly, in my experience the number of times I actually needed 
> something like that is tiny.
...
>
> A very robust approach **for what** ?
>
> What are you trying to do? Why are you indexing into arbitrary positions
> of a list without knowing whether or not there is something there?
>
> List are not dicts and they are used differently. It is very common, and
> useful, to want to look up a key in a dict without knowing if it exists,
> and do something with a default if it doesn't exist. This is so useful

Maybe your missions involve working with people doing properly their job.

Me, I have to deal SOAP government systems, mongodb based API built by
teenagers, geographer data set exports and FTP + CSV in marina systems
(which I happen to work on right now).

3rd party CSV, XML and JSON processing are just a hundred of lines of
try/except on indexing because they have many listings, data positions
is important and a lot of system got it wrong, giving you inconsistent
output with missing data and terrible labeling.

And because life is unfair, the data you can extract is often a mix of
heterogeneous mappings and lists / tuples. And your tool must manage the
various versions of the data format they send to you, some with
additional fields, or missing ones. Some named, other found by position.

This summer, I had to convert a data set provided by polls in africa
through an android form, generated from an XML schema, send as json
using Ajax, then stored in mongodb... to an excel spread sheet (and also
an HTML table and some JS graphs for good measure).

Needingless to say I dealt with a looooot of IndexError. Grepping the
project gives me:

grep -R IndexError | wc -l
33

In contrast I have 32 KeyError (most of them to allow lazy default
value), and 3 decorators.

If special syntax exist for decorators, then surely we can spare a
.get() for lists and tuples.

Apparently IndexError is an important error because if I grep the
virtualenv of the project:

grep -R IndexError | wc -l
733

Ok, it's a pretty large project with 154 dependancies, but it's still
almost 7 IndexError by package on average. So it's not a rare use case.

I also see it regularly in my classes. Students try it because they
learned it works with dict. It makes sense.

Don't dismiss a use case because you don't have it. Python is so
versatile it's used in many diverse areas.


More information about the Python-ideas mailing list