On Wed, Jan 29, 2014 at 3:53 PM, Keith Winston <keithw...@gmail.com> wrote: > I had the impression that Peter was employing tuples because, > as an immutable type, it couldn't inadvertently/inauspiciously > be changed by a user
Per footnote 5 of PEP 249, the parameters need to be in a type that supports __getitem__ (sequence or mapping). In addition to the qmark paramstyle, pysqlite (the development name for the sqlite3 module) supports named parameters: http://docs.python.org/3/library/sqlite3#sqlite3.Cursor.execute For a tuple or list of parameters, pysqlite uses the PyTuple and PyList concrete APIs, respectively. Else for tuple/list subclasses, or other sequence types, it uses the abstract PySequence API. Tuples are the sequence of choice because they're allocated more efficiently, with deallocated tuples cached by size (up to length 20). Additionally, a tuple of constants is stored directly in the code object (allowed because it's immutable), while a list has to be built each time the code is evaluate. For example: >>> code = (lambda: ("Site Name's Harbor.JPG",)).__code__ >>> code.co_consts (None, "Site Name's Harbor.JPG", ("Site Name's Harbor.JPG",)) For a dict with named parameters, pysqlite uses the PyDict concrete API. For a dict subclass (e.g. defaultdict, OrderedDict) it falls back on the abstract PyMapping API. Relevant sqlite3 C APIs: sqlite3_bind_parameter_count sqlite3_bind_parameter_name https://www.sqlite.org/c3ref/bind_parameter_count.html https://www.sqlite.org/c3ref/bind_parameter_name.html sqlite3_bind_null sqlite3_bind_int64 sqlite3_bind_double sqlite3_bind_text sqlite3_bind_blob https://www.sqlite.org/c3ref/bind_blob.html _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
