[Python-ideas] Retrying EAFP without DRY

[julien tayon]

2012/1/24 Carl M. Johnson <cmjohnson.mailinglist at gmail.com>:
>
> On Jan 23, 2012, at 9:00 PM, Nick Coghlan wrote:
>
>> On Tue, Jan 24, 2012 at 3:47 PM, Mike Meyer <mwm at mired.org> wrote:
>>> The argument isn't that we need a new syntax for a small set of loops, it's that the only ways to implement retrying after an exception leave a code smell.
>>
>> Uh, saying "retrying is fundamentally a looping operation" is not a
>> code smell.
>
> I do think there's something code smelly about a retry--if it didn't work the first time, why should it work the second time after you give it a whack? Either whacking is good and you should do it in advance or it's bad and you should do something more sophisticated--but I don't see how creating language level support for retrying would remove the smell. Accessing deeply.nested.methods.and_.properties is a code smell too, even though it has language level support from Python. (You could imagine it being otherwise, if Python insisted that each attribute access get its own line, but that wouldn't remove the smell either.)

When could you need to  retry a second time in a legitimate way?

Mhhh, because you are trying to acquire a DHCP lease, you made a
DHCPDISCOVER, and you have to retry on the same udp connexion you
opened as long as you have no response, or you dont dont have a
timeout, therefore  you need to count the retry/time elapsed.

Following the metaphor of the DHCP lease, where you need to retry with
the same context than the try, you'd then claim that you may also need
DHCPLEASE handling (a low level auth in DHCP) and retry all the way
down from the DHCPDISCOVER if your IP is not accepted after a DHCPNAK.
And then you discover that these problems of error handling with
keeping context would best be handled in an evenemential fashion
rather than with adding a weired hack in sequential programming.

This case, and others are best treated with twisted or tornado, but do
you really want to import tornado or twisted when you need a rough
finite state automata ?
(I don't have the answer)

-- 
Regards,
Jul