this is a dictionary where applications can store arbitrary
data local to a :class:`.Session`.
The contents of :attr:`.Session.info` can be also be initialized
using the ``info`` argument of :class:`.Session` or
:class:`.sessionmaker`.

- went through examples/ and cleaned out excess list() calls

the creation of strong references within the Session;
an object will no longer have an internal reference cycle
created if it's in the transient state or moves into the
detached state - the strong ref is created only when the
object is attached to a Session and is removed when the
object is detached.  This makes it somewhat safer for an
object to have a `__del__()` method, even though this is
not recommended, as relationships with backrefs produce
cycles too.  A warning has been added when a class with
a `__del__()` method is mapped.
[ticket:2708]

if the given object was the subject of a :meth:`.Session.delete`
operation.
- An object that's deleted from a session will be de-associated with
that session fully after the transaction is committed, that is
the :func:`.object_session` function will return None.
[ticket:2658]

- some global cleanup

    state post-flush due to event listeners;
    any states that are marked as "dirty" from an
    attribute perspective, usually via column-attribute
    set events within after_insert(), after_update(),
    etc., will get the "history" flag reset
    in all cases, instead of only those instances
    that were part of the flush.  This has the effect
    that this "dirty" state doesn't carry over
    after the flush and won't result in UPDATE
    statements.   A warning is emitted to this
    effect; the set_committed_state()
    method can be used to assign attributes on objects
    without producing history events. [ticket:2582]

some of these tests are testing

    when unsupported methods are used inside the
    "execute" portion of the flush.   These are
    the familiar methods add(), delete(), etc.
    as well as collection and related-object
    manipulations, as called within mapper-level
    flush events
    like after_insert(), after_update(), etc.
    It's been prominently documented for a long
    time that  SQLAlchemy cannot guarantee
    results when the Session is manipulated within
    the execution of the flush plan,
    however users are still doing it, so now
    there's a warning.   Maybe someday the Session
    will be enhanced to support these operations
    inside of the flush, but for now, results
    can't be guaranteed.