python - Calling __enter__ and __exit__ manually -

python - Calling __enter__ and __exit__ manually -

i've googled calling __enter__ manually no luck. let's imagine have mysql connector class uses __enter__ , __exit__ functions (originally used with statement) connect/disconnect database.

and let's have class uses 2 of these connections (for illustration info sync). note: not real-life scenario, seems simplest example.

easiest way create work class this:

class datasync(object): def __init__(self): self.master_connection = mysqlconnection(param_set_1) self.slave_connection = mysqlconnection(param_set_2) def __enter__(self): self.master_connection.__enter__() self.slave_connection.__enter__() homecoming self def __exit__(self, exc_type, exc, traceback): self.master_connection.__exit__(exc_type, exc, traceback) self.slave_connection.__exit__(exc_type, exc, traceback) # real operation functions # simple usage illustration datasync() sync: records = sync.master_connection.fetch_records() sync.slave_connection.push_records(records)

q: okay (is there wrong) phone call __enter__/__exit__ manually this?

pylint 1.1.0 didn't issue warnings on this, nor have found article (google link in beggining).

and calling:

try: # db query except mysql.serverdisconnectedexception: self.master_connection.__exit__(none, none, none) self.master_connection.__enter__() # retry

is good/bad practice? why?

no, there's nil wrong that. there places in standard library it. multiprocessing module:

class semlock(object): def __init__(self, kind, value, maxvalue, *, ctx): ... try: sl = self._semlock = _multiprocessing.semlock( kind, value, maxvalue, self._make_name(), unlink_now) except fileexistserror: pass ... def __enter__(self): homecoming self._semlock.__enter__() def __exit__(self, *args): homecoming self._semlock.__exit__(*args)

or tempfile module:

class _temporaryfilewrapper: def __init__(self, file, name, delete=true): self.file = file self.name = name self.delete = delete self._closer = _temporaryfilecloser(file, name, delete) ... # underlying __enter__ method returns wrong object # (self.file) override homecoming wrapper def __enter__(self): self.file.__enter__() homecoming self # need trap __exit__ ensure file gets # deleted when used in statement def __exit__(self, exc, value, tb): result = self.file.__exit__(exc, value, tb) self.close() homecoming result

the standard library examples aren't calling __enter__/__exit__ 2 objects, if you've got object that's responsible creating/destroying context multiple objects instead of one, calling __enter__/__exit__ of them fine.

the potential gotcha handling homecoming values of __enter__ __exit__ calls objects you're managing. __enter__, need create sure you're returning whatever state required user of wrapper object with ... <state>: call. __exit__, need decide if want propagate exception occurred within context (by returning false), or suppress (by returning true). managed objects seek either way, need decide makes sense wrapper object.

python python-3.x contextmanager