Vernon D. Cole <vernondc...@gmail.com> wrote:
> > Since both "Rows" objects, and "Row" objects, obey the sequence API, this > design satisfies the PEP requirements that we return a sequence of sequences. > It will also do much more. If the PEP had been written to require a list of > tuples, none of these other operations would have been possible. I applaud > the PEP authors for avoiding the temptation to over-specify. Please understand, in no way am I calling for the spec to indicate a “list of tuples” as a fixed system. As is customary in Python, I am calling for it to specify a list-*like* object of tuple-*like* objects. The current problem is that the widely accepted semantics of tuples, that they are “usually” [1] data structures of heterogeneous elements [2], are being disobeyed in the case of the MySQL drivers, in the name of “immutability” above all other concerns. These semantics apply to the Python DBAPI so well that the Python DBAPI is even used as a leading example as to what the semantic difference is between a list and a tuple [3]. I don’t believe that adodbapi suffers from this problem. [1] The various articles and blogs regarding tuples typically will qualify their guidance with words like “typically”, “usually”, etc. As they should. However, I don’t think that the result set returned by cursor.fetchall() qualifies as an “unusual” and/or “atypical” use case for lists vs. tuples. It is the *idiomatic* use case. [2] https://docs.python.org/2/tutorial/datastructures.html#tuples-and-sequences [3] http://news.e-scribe.com/397 > [By the way, both Rows and Row objects are made immutable, so that an unwary > programmer does not receive an unwelcome surprise by attempting to alter data > without using an SQL statement.] I would actually favor the result list to be an immutable one as well, and the ideal structure would be an immutable list (which is of course entirely straightforward in Python). It’s unusual that Marc suggests the collection is explicitly mutable, and that this is a common use case. Overall though, I don’t care much that the collection is mutable or not though in this area as well, a clearer specification would only serve the purpose to eliminate this decision / discussion needing to happen at the endpoints of every DBAPI driver. A spec that provides clear guidance rather than loose suggestions would save a lot of effort. Such a spec is of course more difficult to produce, but IMHO would be worth it. > > > > > We have made this more general in the DB-API to allow authors to > > create e.g. result set objects which implement the sequence API > > and row objects which also implement sequence API. > > > > I know several database modules which provide ways to have the > > fetch methods return row objects, but I'm not aware of ones which > > implement a result set object. > > > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > https://mail.python.org/mailman/listinfo/db-sig _______________________________________________ DB-SIG maillist - DB-SIG@python.org https://mail.python.org/mailman/listinfo/db-sig
