[python-win32] adodbapi: paramstyle 'named' doesn't work as expected

Vernon D. Cole vernondcole at gmail.com
Mon Feb 25 03:20:31 EST 2019


Sibyille:
  Thanks for the report and the excellent analysis.  I was afraid no one
would ever use "named" paramstyle.

Dennis:
  Any code suggestion would be very welcome. Would you be able to suggest a
patch?
--
Vernon Cole



On Sat, Feb 23, 2019 at 7:30 AM Sibylle Koczian <nulla.epistola at web.de>
wrote:

> Am 21.02.2019 um 16:26 schrieb Dennis Lee Bieber:
> >
> >       If I were coding something, I'd likely use the native style to
> reduce
> > the cost of conversion overhead. Relatively speaking, that name
> extraction
> > code is /slow/ -- it splits the query on :, then loops over each
> character
> > looking for something (non-alphanumeric and not _) on which to terminate
> > the resulting name... and that loop is done at Python source code level
> (it
> > doesn't even use a
> >
> >               for i,c in enumerate(chunk):
> >
> > which would exit the loop on the end of the chunk; instead it manually
> > increments the counter to be "next character" [which fails when there is
> no
> > next character].
> >
> >
>
> Well - I started to write my application without much thought about
> execution speed, because the database tables concerned are small to very
> small. If I can use a dictionary for query parameters then the function
> producing the parameters doesn't need to know much about the SQL query
> using them. That's why I like pyformat and named. Looking at the apibase
> code I think pyformat might be a little bit faster?
>
> But when I saw things didn't work as expected that had to be cleared up
> in any case.
>
> Greetings
> Sibylle
> _______________________________________________
> python-win32 mailing list
> python-win32 at python.org
> https://mail.python.org/mailman/listinfo/python-win32
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-win32/attachments/20190225/56d0cb25/attachment.html>


More information about the python-win32 mailing list