On 27.08.2020 15:17, Alex Hall wrote: > On Thu, Aug 27, 2020 at 3:09 PM M.-A. Lemburg <m...@egenix.com> wrote: > >> I disagree on the above assessment. I have had such a get() builtin >> in mxTools for more than 20 years now and found that I hardly ever >> used it: >> >> https://www.egenix.com/products/python/mxBase/mxTools/doc/#_Toc293606201 >> >> The reason is simple: unlike for dicts, where you often expect >> non-existing items (e.g. in keyword arguments, config files, etc.), >> having a missing index position in a list which you parse is >> almost always an error. >> >> Now, errors should be clearly marked and handled as such, hence >> having a try-except is the better coding strategy. >> >> For those cases, where a list can have a variable >> number of entries (e.g. optional arguments, file lists, etc.), >> code should clearly branch on list length and then determine the >> right strategy to fetch items. > > > I'm copying my earlier post because apparently linking to it repeatedly has > no effect and people keep on claiming that this method wouldn't be useful > while not saying a word about the evidence I presented that it would be. > > dict.get is definitely much more useful. But list.get is still useful > reasonably often. > > You can see quite a bit of demand for the method here: > https://stackoverflow.com/questions/5125619/why-doesnt-list-have-safe-get-method-like-dictionary > > Below are some use cases I found and how they could be refactored with > .get. Apart from the first one, they were all found simply by grepping for > `except IndexError`. It's pretty easy to pick obvious use cases out from > there. In some cases readability suffers a bit and using .get might not be > the best idea, but I've included them anyway so that we can see what > over-eager usage of the method might look like.
If I'm not mistaken, all those listed cases fall under the second case I mentioned (branching on length). If your API allows for optional list entries, then it's better to branch on length (e.g. as in the pytest case). If this happens only in exceptional cases, use try-except (most other cases you listed). Both coding styles make the intent clear without doubt. As mentioned before, I had access to such a builtin for many years, but hardly ever chose to use it and instead opted for the more explicit branching on length. IMO, being able to write something with fewer key strokes is not always a good idea. Unless you write code only for yourself, it's usually better to emphasize on intent rather than brevity. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Aug 27 2020) >>> Python Projects, Coaching and Support ... https://www.egenix.com/ >>> Python Product Development ... https://consulting.egenix.com/ ________________________________________________________________________ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/ _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/B74T6L6FQYPA47SJDXIIF4RBH3BF2JW5/ Code of Conduct: http://python.org/psf/codeofconduct/
