Em qui, 27 de ago de 2020 10:37, M.-A. Lemburg <m...@egenix.com> escreveu:
> 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. > In this case is pretty obvious the intent and this is an know abstraction. Avoid brevity will not make it cleaner. IMHO, explicitng index bounds and try/catch are distracting noise which hides intent instead. Also .get() would not prevent anybody from explicity checking bounds or catching index exceptions when appropriate > > -- > 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/25OXHPNDVYRYOOWU6YDRL3PLQVLIG2K5/ Code of Conduct: http://python.org/psf/codeofconduct/
