Rob Cliffe via Python-ideas writes:
> Steven d'Aprano wrote:
> > You don't have to agree with Serhiy's preference to recognise that there
> > are cases where this proposal will save no lines of code. And probably
> > not rare cases -- I expect that they will be much more common than the
> > short examples you quote:
> >
> >> If you read the PEP you will find plenty of short examples:
> >>
> >> process(dic[key] except KeyError: None)
> >> value = (lst[2] except IndexError: "No value")
> >> cond = (args[1] except IndexError: None)
> >> pwd = (os.getcwd() except OSError: None)
> >> e.widget = (self._nametowidget(W) except KeyError: W)
> >> line = (readline() except StopIteration: '')
> >> etc.
> > The first is a poor example because that can so easily be written as:
> >
> > process(dic.get(key))
I disagree with Steven here to the extent that one purpose of the PEP
is to provide a common idiom that allows us to express this *without*
proliferating methods like dict.get. I hope he will unpack this by
arguing "d.get(k)" is *better* than "(d[k] except KeyError: None)".
Given my present understanding of the situation, I would be perfectly
happy with an outcome where methods like dict.get were deprecated (as
a matter of style and TOOWTDI, I don't mean DeprecationWarning) in
favor of the uniform except-clause syntax, unless there's a reason
this syntax is *bad*. There are many times I choose to split a long
if-else expression across lines, and others where I choose the
statement form, and of course I use "x or default" instead of "x if x
else default". I see no reason why this construct wouldn't "work" the
same way, although it might be much less common (then again, it might
be *more* common than if-else expressions).
The kind of anti-except-expression argument I have in mind can be
exemplified using the fourth example:
pwd = (os.getcwd() except OSError: None)
where I would find the argument that this really is an environmental
condition that probably shouldn't be papered over with "pwd=None" in
almost all contexts, and therefore should be emphasized with a try
*statement*, pretty plausible. But that might be a style argument
("use 'try', not 'except' expressions when the Error indicates a
broken environment rather than an uncommon but reasonable state"),
rather than an argument that we *should not* unify these usages with a
single idiom.
Interestingly, Steven takes the opposite position:
> > The fourth example of os.getcwd is excellent.
I just don't know. "Infinite are the arguments of mages." ;-)
Steve
_______________________________________________
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/KZFK5GB3W7RW67F4CXD73QD4OIKMTMAF/
Code of Conduct: http://python.org/psf/codeofconduct/
