On 23.05.2013 23:37, Chris Clark wrote: > On Thu, 23 May 2013 13:33:20 -0700, Chris Clark <chris.cl...@actian.com> > wrote: >> On Thu, 23 May 2013 16:59:27 +0200, M.-A. Lemburg <m...@egenix.com> wrote: >>> On 22.05.2013 00:52, Michael Bayer wrote: >>>> As a total aside, I also have issues with some DBAPIs that accept *only* a >>>> list for the >>>> "sequence", others that accept *only* a tuple (this may be only when the >>>> parameter list is >>>> empty, however). So specifying the significance of "empty" parameter >>>> lists as well as how to >>>> test for "sequence" would be nice too, so that I can hit the DBAPI authors >>>> with bug reports >>>> backed up by the spec. >>> The DB-API is already clear on this: any sequence should be >>> accepted for .execute() and any sequence of sequences for .executemany(). >>> >>> Spelling out the special case of passing an empty sequence to >>> .execute() and .executemany() would probably be wise. For .execute() >>> this would only be valid for a statement that doesn't have parameter >>> markers. For .executemany() this would be the same as a no-op (and >>> only serve a purpose on the basis that it makes writing algorithms >>> easier). >>> >> >> I'd like to suggest that if the bind parameter is nonzero (i.e. __nonzero__ >> method call) then it >> is assumed there are no params. This way we don't have to get into is it an >> empty sequence, is it >> None, etc. > > Apologies, I meant the reverse :-( > > I'd like to suggest that if the bind parameter is nonzero (i.e. __nonzero__ > method call returns > True) then it is assumed there *are* params. This way we don't have to get > into is it an empty > sequence, is it None, etc.
There is no __nonzero__ in Python 3 anymore. The method was renamed to __bool__ :-) I'm also not sure whether we should allow any of these: .execute(sql, None) .executemany(sql, None) .executemany(sql, [None]) In order to support your suggestion, database module would have to call the __nonzero__/__bool__ slot on the parameters, which could be an expensive operation with no real value in case the parameters are not None, or even be impossible in the case of iterators. Using the slot, we'd also allow things like these: .execute(sql, 0) .executemany(sql, 0.0) .executemany(sql, [0]) which can hide programming errors. Using the __len__ slot would work, though, unless you have an iterator... Which leads to another idea for DB-API 3: I think we should allow iterators for the parameter list in .executemany(), and perhaps even for the parameter sequence in .execute(). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 24 2013) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2013-07-01: EuroPython 2013, Florence, Italy ... 38 days to go ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
