Steps to reproduce
Wrap a lock in a with statement, and throw an exception in the related execution block
Actual behavior
the lock is still in place even after the with block execution is finished
Expected behavior
the lock is released as soon as the with block execution is finished
Steps to reproduce
This is the easiest way I've found to reproduce it
from elmo.api.client import ElmoClient
BASE_URL = "https://connect3.elmospa.com"
VENDOR = "yourvendor"
USERNAME = "yourname"
PASSWORD = "*****"
CODE = "*****"
if __name__ == '__main__':
client = ElmoClient(BASE_URL, VENDOR)
client.auth(USERNAME, PASSWORD)
with client.lock(CODE) as c:
c.disarm()
assert False
Side notes
The snippet I've provided is a naive example. In my code the error is thrown by a call to vibrator.vibrate() (from plyer), which in turn catches the error and simply logs a message if the vibration service is not in place.
Given that I'm not a pythonist, when I write with client.lock()... I'd expect a semantic similar to a try...finally where at the end the lock is released.
Filled as per this comment of #55.
Steps to reproduce Wrap a lock in a with statement, and throw an exception in the related execution block
Actual behavior the lock is still in place even after the with block execution is finished
Expected behavior the lock is released as soon as the with block execution is finished
Steps to reproduce This is the easiest way I've found to reproduce it
Side notes The snippet I've provided is a naive example. In my code the error is thrown by a call to
vibrator.vibrate()
(from plyer), which in turn catches the error and simply logs a message if the vibration service is not in place.Given that I'm not a pythonist, when I write
with client.lock()...
I'd expect a semantic similar to a try...finally where at the end the lock is released.Some references: