Confused compare function :)

[Dave Angel]

On 12/06/2012 08:58 AM, Chris Angelico wrote:
> On Fri, Dec 7, 2012 at 12:33 AM, Thomas Rachel
> <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915 at spamschutz.glglgl.de>
> wrote:
>> Am 06.12.2012 09:49 schrieb Bruno Dupuis:
>>
>>> The point is Exceptions are made for error handling, not for normal
>>> workflow. I hate when i read that for example:
>>>
>>>      try:
>>>          do_stuff(mydict[k])
>>>      except KeyError:
>>>          pass
>> I would do
>>
>>     try:
>>         value = mydict[k]
>>     except KeyError:
>>         pass
>>     else:
>>         do_stuff(k)
>>
>> Why? Because do_stuff() might raise a KeyError, which should not go
>> undetected.
> (Assuming first off that you meant "do_stuff(value)", not
> "do_stuff(k)", in that last line)
>
> That has quite different functionality, though. The original wouldn't
> have called do_stuff at all if k is not in dict, behaviour which is
> matched by both his EAFP and his LBLY. But your version, in the event
> of a KeyError, will call do_stuff with the previous value of value, or
> raise NameError if there is no such previous value.

Nope.  The else clause will only execute if no exception occurs in the
value= line.

>  I don't think
> that's intentional.
>
> The only way around it that I can see is an extra condition or jump -
> something like:
>
> def call_if_present(mydict,k,do_stuff):
>     """Equivalent to
>     do_stuff(mydict[k])
>     if the key is present; otherwise, does not call do_stuff, and
> returns None."""
>     try:
>         value = mydict[k]
>     except KeyError:
>         return
>     return do_stuff(value)
>
> It'll propagate any other exceptions from the subscripting (eg
> TypeError if you give it a list instead of a dict), and any exceptions
> from do_stuff itself. But it's getting a bit unwieldy.
>
> ChrisA


-- 

DaveA