Why is this pattern discouraged in SQLAlchemy? - multithreading

Question

When reading the official SQLAlchemy documentation, I found the example below:
### this is the **wrong way to do it** ###
class ThingOne(object):
def go(self):
session = Session()
try:
session.query(FooBar).update({"x": 5})
session.commit()
except:
session.rollback()
raise
class ThingTwo(object):
def go(self):
session = Session()
try:
session.query(Widget).update({"q": 18})
session.commit()
except:
session.rollback()
raise
def run_my_program():
ThingOne().go()
ThingTwo().go()
I don't really understand the drawbacks for this pattern. Actually I can think of one major ADVANTAGE to this: in a multi-threading context, this pattern can ensure that each session instance is a local variable to the function that actually uses it.
Could someone enlighten me by giving some potential drawbacks for the example above? Thanks.
Edit: As an example for advantages in a multiple threading context. If we have a web application server class here:
class WebApp:
def update(self, **kwargs):
session = Session()
try:...
Here, the page handler update has its own local variable session, so no matter how many threads it runs, it's always safe. In constrast, using another layer of function to contain session would introduce way more complexity in this case

Answer 1

In simple terms, sqlalchemy recommends that the handling of session is not mixed with the manipulation of data. As you can see from the next example.
### this is a **better** (but not the only) way to do it ###
class ThingOne(object):
def go(self, session):
session.query(FooBar).update({"x": 5})
class ThingTwo(object):
def go(self, session):
session.query(Widget).update({"q": 18})
def run_my_program():
session = Session()
try:
ThingOne().go(session)
ThingTwo().go(session)
session.commit()
except:
session.rollback()
raise
finally:
session.close()
ThingOne and ThingTwo is just doing it's thing in doing CRUD but the handling of session is done outside of those objects.
For multi threading, session scopes are thread local objects. Meaning, they can't be shared by different threads. You can declare them as what you have specified but it doesn't mean that handling session from an external entity is bad choice either.