> > 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. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
