Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #91976
| Path | csiph.com!usenet.pasdenom.info!news.redatomik.org!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!feeds.phibee-telecom.net!news.panservice.it!feed.xsnews.nl!border01.ams.xsnews.nl!feeder01.ams.xsnews.nl!abp001.ams.xsnews.nl!frontend-F10-04.ams.news.kpn.nl |
|---|---|
| From | Cecil Westerhof <Cecil@decebal.nl> |
| Newsgroups | comp.lang.python |
| Subject | Re: Retrying to send message |
| Organization | Decebal Computing |
| References | <87egltht87.fsf@Equus.decebal.nl> <mailman.108.1433338144.13271.python-list@python.org> |
| X-Face | "(y8cC@tg_12{">GF'UXTW]FHI2wMiZNrnf'1EFQ&O#$m:f#O7+7}kR<J%a^F2lh4[N~Yz4 nSp#c+aQo1b5=?HcNEkQ7QzF<])O3X4MDL/AYjys&*mt>,v+Pti8=Vi/Z"g^?b"E |
| X-Homepage | http://www.decebal.nl/ |
| Date | Wed, 03 Jun 2015 18:15:16 +0200 |
| Message-ID | <876174ix9n.fsf@Equus.decebal.nl> (permalink) |
| User-Agent | Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) |
| Cancel-Lock | sha1:Ibl+Ith1ly4IogP66fXLpG2XHIU= |
| MIME-Version | 1.0 |
| Content-Type | text/plain; charset=utf-8 |
| Content-Transfer-Encoding | 8bit |
| Lines | 84 |
| NNTP-Posting-Host | 81.207.62.244 |
| X-Trace | 1433348996 news.kpn.nl 20684 81.207.62.244@kpn/81.207.62.244:36664 |
| Xref | csiph.com comp.lang.python:91976 |
Show key headers only | View raw
Op Wednesday 3 Jun 2015 15:29 CEST schreef Chris Angelico:
> On Wed, Jun 3, 2015 at 10:27 PM, Cecil Westerhof <Cecil@decebal.nl> wrote:
>> def send_message(account_id, message, max_tries,
>> terminate_program): error_msg = 'Something went wrong with: ' +
>> message not_send = True tries = 0 while not_send: try:
>> Core().update_status(account_id, message) except
>> libturpial.exceptions.ServiceOverCapacity: tries += 1 print('Tried
>> to send it {0} times'.format(tries)) if tries >= max_tries:
>> terminate_program(error_msg) time.sleep(60) except:
>> terminate_program(error_msg) else: not_send = False
>>
>> Is this a reasonable way to implement this, or is another way
>> better? Well, maybe the timeout should be a parameter also. ;-)
>
> I'd skip the not_send flag and do the logic thusly:
>
> while True:
> try:
> update_status as above
> break
> except ServiceOverCapacity:
> as above
Yes that is much better. I now made it:
def send_message(account_id, message, max_tries, give_error, wait_time = 60):
error_msg = 'Something went wrong with: ' + message
tries = 0
while True:
try:
Core().update_status(account_id, message)
break
except libturpial.exceptions.ServiceOverCapacity:
tries += 1
print('Tried to send it {0} times'.format(tries))
if tries >= max_tries:
give_error(error_msg)
return
time.sleep(wait_time)
except:
give_error(error_msg)
return
> And I'd also skip the bare except clause. If you get any sort of
> exception, whether it's a bug, a failure from libturpial, a network
> error, or anything else, your code will just terminate with a bland
> and useless message. Much better to simply let the exception bubble
> up.
I kept the except. I like to see the message that went wrong. ;-)
Also, in my case give_error terminates the program, but it never hurts
to make functionality generic, so I added return statements. Not
break, because on error you should leave the function. Break would in
this instance do the same, but I find this neater.
>> Also the documentation of time.sleep says:
>> The actual suspension time may be less than that requested because
>> any caught signal will terminate the sleep() following execution
>> of that signal’s catching routine.
>>
>> My program does not much else as sending the message. So I think it
>> is not necessary to cover for this possibility. Are I assuming to
>> much?
>
> I wouldn't worry too much about a signal cutting your sleep short;
> it doesn't look to me as if "exactly sixty seconds" is all that
> crucial here. If your program sleeps for 42.645 seconds and then
> gets woken up by a signal, and you retry a bit sooner than you
> otherwise would have, is it going to break anything? If not, just
> ignore that possibility.
Correct, so I did not assume to much. :-D
Usually I check parameters. But I understood that is not the Python
way. For example a wait_time of 1, or negative is not useful. Also a
max_tries of 10 ** 12 would not be very useful. But I can put the
burden of the problem on the caller of the function?
--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Retrying to send message Cecil Westerhof <Cecil@decebal.nl> - 2015-06-03 14:27 +0200
Re: Retrying to send message Chris Angelico <rosuav@gmail.com> - 2015-06-03 23:29 +1000
Re: Retrying to send message Cecil Westerhof <Cecil@decebal.nl> - 2015-06-03 18:15 +0200
Re: Retrying to send message MRAB <python@mrabarnett.plus.com> - 2015-06-03 19:12 +0100
Re: Retrying to send message Ethan Furman <ethan@stoneleaf.us> - 2015-06-03 11:28 -0700
Re: Retrying to send message Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-06-03 21:37 +0100
Re: Retrying to send message Chris Angelico <rosuav@gmail.com> - 2015-06-04 08:00 +1000
Re: Retrying to send message Ethan Furman <ethan@stoneleaf.us> - 2015-06-03 16:15 -0700
Re: Retrying to send message Cecil Westerhof <Cecil@decebal.nl> - 2015-06-04 07:13 +0200
csiph-web