On Wed, Feb 29, 2012 at 3:30 AM, Daniele Varrazzo
<daniele.varrazzo(a)gmail.com> wrote:
Thank you for all the improvements: the new attribute, the subtype
check and the suggestion about how to work around the tracebacks: I
had't had time today to work on it but tomorrow will implement all the
suggested changes and keep on testing.
So, I've had another hack night implementing what discussed here.
The subtype check works flawlessly, great!
The new flags have been really helpful, and have allowed to model
perfectly the exceptions flow into the library.
A small family of functions couldn't be modeled: stuff like returning
a char * on success, NULL+exception on failure. In my case they were
not so many and are not exposed, so it's not been a problem to convert
"char *foo()" into "int foo(char **)" and flag them as raising on
negative value <
https://github.com/dvarrazzo/psycopg/commit/f2e4a8ed>.
From a style PoV, I find the CPYCHECKER_* attribute macro too verbose
to be practical: I've given them shorter aliases (BORROWED, STEALS(n),
RAISES, RAISES_NEG)
<
https://github.com/dvarrazzo/psycopg/commit/5bfb6cde>.
Unfortunately, changing the signature for the handler functions for
the "O&" format
<
https://github.com/dvarrazzo/psycopg/commit/4d15b973>
has't worked as expected: the traceback is still there. I also notice
that these functions probably cannot be modeled with the current set
of flags: in case of success they return 1 and steal a reference from
the 1st argument, in case of failure return 0 and don't steal. I think
the usage for this type of functions is too limited to be of concern
though, ok not to make it crash, but probably modeling them is not a
priority.
Last small thing to report: there is a funny false positive that has
required the patch in
<
https://github.com/dvarrazzo/psycopg/commit/94327872>: without it,
the function was reported as returning -1 without exception set. Is it
the expected behaviour (e.g. assuming that the value of
curs->conn->async_cursor could change in another thread)?
Will try to work around the source file that fails compiling tomorrow,
and try to do something else for the plugin. I've noticed the
PyString_AsStringAndSize missing, but its semantic is peculiar
(returns a buffer in a char ** on success... don't know where to copy
that!), so I will really need to learn something to implement it.
I'd like an opinion from you: Ideally, I imagine running the checker
as a QA step, for instance before releasing. It could be run by
buildbot after every commit etc. There are a few issues that seem hard
to be solved, and OTOH is pretty clear that they are not a real
problem. Do you have in program a strategy to eventually silence them
somehow, so that a script may run the analysis and have a clean result
even if there are a few known false positives? Or do you think the
plugin will only remain as an interactive help?
Cheers,
-- Daniele