Message 146670 - Python tracker

➜

This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author	ncoghlan
Recipients	ncoghlan
Date	2011-10-31.00:32:24
SpamBayes Score	7.12824e-05
Marked as misclassified	No
Message-id	<1320021145.59.0.53370875256.issue13299@psf.upfronthosting.co.za>
In-reply-to

Content
Currently, sqlite3 allows rows to be easily returned as ordinary tuples (default) or sqlite3.Row objects (which allow dict-style access). collections.namedtuple provides a much nicer interface than sqlite3.Row for accessing ordered data which uses valid Python identifiers for field names, and can also tolerate field names which are not valid identifiers. It would be convenient if sqlite3 provided a row factory along the lines of the one posted here: http://peter-hoffmann.com/2010/python-sqlite-namedtuple-factory.html (except with smarter caching on the named tuples)

Currently, sqlite3 allows rows to be easily returned as ordinary tuples (default) or sqlite3.Row objects (which allow dict-style access).

collections.namedtuple provides a much nicer interface than sqlite3.Row for accessing ordered data which uses valid Python identifiers for field names, and can also tolerate field names which are *not* valid identifiers.

It would be convenient if sqlite3 provided a row factory along the lines of the one posted here:
http://peter-hoffmann.com/2010/python-sqlite-namedtuple-factory.html

(except with smarter caching on the named tuples)

History
Date	User	Action	Args
2011-10-31 00:32:25	ncoghlan	set	recipients: + ncoghlan
2011-10-31 00:32:25	ncoghlan	set	messageid: <1320021145.59.0.53370875256.issue13299@psf.upfronthosting.co.za>
2011-10-31 00:32:24	ncoghlan	link	issue13299 messages
2011-10-31 00:32:24	ncoghlan	create