On Wed, Mar 01, 2017 at 02:56:44AM +0100, Michel Desmoulin wrote: > > 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?".
These days, it might be better to write it as: first_item = alist[0] if len(alist) else "ham" but I remember the days when slicing was normal and using the `or` trick was standard operating procedure. > You are trying to hard to provide a counter argument here. In context, all I'm saying is that you don't *have* to catch IndexError. There are alternatives. That is all. > 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. This is all very well and good, and I feel your pain for having to deal with garbage data, but I don't see how this helps you. You talk about missing data, but lists cannot contain missing data from the middle. There's no such thing as a list like: [0, 1, 2, 3, , , , , , , 10, 11, 12] where alist[3] and alist[10] will succeed but alist[4] etc will raise IndexError. So I'm still trying to understand what this proposal gets you that wouldn't be better solved using (say) itertools.zip_longest or a pre-processing step to clean up your data. > 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. Maybe I'm underestimating just how awful your data is, but I'm having difficulty thinking of a scenario where you don't know what kind of object you are processing and have to write completely type-agnostic code: for key_or_index in sequence_of_keys_or_indexes: result = sequence_or_mapping[key_or_index] I'm sure that there is lots of code where you iterate over dicts: for key in keys: result = mapping.get(key, default) and likewise code where you process lists: for i in indexes: try: result = sequence[i] except IndexError: result = default # could be re-written using a helper function: for i in indexes: result = get(sequence, i default) but I've never come across a data-processing situation where I didn't know which was which. That second version with the helper function would be *marginally* nicer written as a method call. I grant you that! > 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. So 33 is "a looooot", but 32 KeyErrors is "in contrast" and presumably a little. > 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. You don't know that every one of those can be replaced by list.get(). Some of them might be raising IndexError; some of them may be documenting that a function or method raises IndexError; etc. > I also see it regularly in my classes. Students try it because they > learned it works with dict. It makes sense. I never said it didn't. But I wonder whether it gives *enough* benefit to be worth while. -- Steve _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/