probably be one in test_query or test_unicode...)
- fix up test_unitofwork

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

a rollback() before re-raising, so that the stack
trace is preserved from sys.exc_info() before entering
the rollback.  This so that the traceback is preserved
when using coroutine frameworks which may have switched
contexts before the rollback function returns.
[ticket:2703]

labeled columns when apply_labels() is used; this mode
produces a SELECT where each column is labeled as in
<tablename>_<columnname>, to remove column name collisions
for a multiple table select.   The fix is that if two labels
collide when combined with the table name, i.e.
"foo.bar_id" and "foo_bar.id", anonymous aliasing will be
applied to one of the dupes.  This allows the ORM to handle
both columns independently; previously, 0.7
would in some cases silently emit a second SELECT for the
column that was "duped", and in 0.8 an ambiguous column error
would be emitted.   The "keys" applied to the .c. collection
of the select() will also be deduped, so that the "column
being replaced" warning will no longer emit for any select()
that specifies use_labels, though the dupe key will be given
an anonymous label which isn't generally user-friendly.
[ticket:2702]

    "tuple" rows that contain
    types which aren't hashable, by setting the flag
    "hashable=False" on the corresponding TypeEngine object
    in use.  Custom types that return unhashable types
    (typically lists) can set this flag to False.
    [ticket:2592]
  - [bug] Applying a column expression to a select
    statement using a label with or without other
    modifying constructs will no longer "target" that
    expression to the underlying Column; this affects
    ORM operations that rely upon Column targeting
    in order to retrieve results.  That is, a query
    like query(User.id, User.id.label('foo')) will now
    track the value of each "User.id" expression separately
    instead of munging them together.  It is not expected
    that any users will be impacted by this; however,
    a usage that uses select() in conjunction with
    query.from_statement() and attempts to load fully
    composed ORM entities may not function as expected
    if the select() named Column objects with arbitrary
    .label() names, as these will no longer target to
    the Column objects mapped by that entity.
    [ticket:2591]