Return a namedtuple for inserted_primary_key

[v]

Hello,

It's a bit annoying that the inserted_primary_key is a list instead of something with some useful metadata. If it were a namedtuple instead, a user could access the keys by name in addition to the existing method (by index).

The documentation for namedtuple even recommends usage like this:

Named tuples are especially useful for assigning field names to result tuples returned by the csv or sqlite3 modules

(from https://docs.python.org/3/library/collections.html#collections.namedtuple)

For what it's worth, psycopg2 allows for namedtuple cursors: http://initd.org/psycopg/docs/extras.html#namedtuple-cursor

[Mike Bayer]

the only major issue with this is one of performance. particularly with inserted_primary_key, we're dealing with a namedtuple that in a naive implementation would be produced on every query execution. To see how expensive this is, just look at the source for Python's namedtuple; it's excessive to create new ones. The benching here contrasts three different named tuple approaches comparing startup cost vs. many iterations cost. So we'd likely use the lw keyed tuple, but that is still not without cost and will add to that of the ORM's flush process, although a good way to ameliorate this would be to cache these keyed tuples along with the Table objects that corresponds to the insert.

this would be fine for 1.0 if a PR with test support and the above caching were provided, but I'm milestoning this at 1.1 for now as I am trying to limit what's left to do before 1.0 can have beta releases.

[Mike Bayer]

to implementors:

if we use a traditional collections.NamedTuple, the production of the tuple must be cached most likely using @memoized_property. It can potentially be a semi-private member of the PrimaryKeyConstraint construct.