:class:`.Query` and in other situations where selects or joins
were aliased (such as joined table inheritance) could fail if a
user-defined :class:`.Column` subclass were used in the expression.
In this case, the subclass would fail to propagate ORM-specific
"annotations" along needed by the adaptation.  The "expression
annotations" system has been corrected to account for this case.
[ticket:2918]

target of :paramref:`.relationship.secondary` for the purposes
of creating very complex :func:`.relationship` join conditions.
The change includes adjustments to query joining, joined eager loading
to not render a SELECT subquery, changes to lazy loading such that
the "secondary" target is properly included in the SELECT, and
changes to declarative to better support specification of a
join() object with classes as targets.

Fix TypeError for class_mapper called w/ iterable

are used with :func:`.joinedload()` (thereby causing a regression
in joined eager loading) as well as :func:`.aliased`
in conjunction with the ``flat=True`` flag and joined-table inheritance;
basically multiple joins across a "parent JOIN sub" entity using different
paths to get to a target class wouldn't form the correct ON conditions.
An adjustment / simplification made in the mechanics of figuring
out the "left side" of the join in the case of an aliased, joined-inh
class repairs the issue. [ticket:2908]

When the class_ passed is not a mapped class but is actually an iterable, the string formatting operation fails with a TypeError, and the expected ArgumentError is not raised. Calling code which is using reflection and expects this error will fail (e.g. the sadisplay module).

correct string class when setting up a backref based on a name,
therefore causing the error "too many values to unpack".  This was
related to the Py3k conversion. [ticket:2901]