#21 Patch that attempts to deal with Zope

closed-out-of-date
nobody
None
5
2010-07-06
2005-03-23
No

This patch attempts to deal properly with Zope code.
It's related to bug #856597.

Basically, what happens in this bug is that pychecker
gets an internal error trying to access the co_flags
attribute of a func_code class. The func_code class
itself is some sort of strange Zope class called
Shared.DC.Scripts.Signature.FuncCode. At last count,
this class is missing the following methods or members
which pychecker relies on (as of Zope 2.6.4, anyway):

co_code
co_filename
co_firstlineno
co_flags
co_name
co_lnotab
__getitem__

That means that fixing this bug potentially means a
large number of code changes, with almost a special
case for Zope everywhere that one of these attributes
is referred to (there already are a few such special
cases). That's a really ugly solution in general.

Instead, I propose to find the one or two places where
it's possible for us to ignore this class, and
standardize on a way to do that. That's what this
patch implements. It creates a new function
CodeChecks.funcCodeIsBroken() that identifies a broken
func_code instance. Then,
CodeChecks._checkFunctionArgs() and
function.same_signature() call funcCodeIsBroken() to
decide whether they should deal with the func_code they
have been handed or just ignore it and go on.

Ignoring the broken class seems to make more sense than
trying to special-case every check, which would
probably have to result in a bunch of bogus values for
unusable attributes anyway.

I also modify the function._co_flags_equal() function
to just deal with a missing co_flags attribute. I
decided that since the function was already pretty much
abstracted off from everything else, it was OK.

After applying this patch, I was able to run the test
case for bug #856597 with no problems. Pychecker
notices a huge number of Zope-related warnings, but it
doesn't get any internal errors processing the code.
Unfortunately, I can't find a way to blacklist the Zope
warnings, but that's another bug. :(

I also ran all of the pychecker unit tests using Python
2.1, 2.2, 2.3 and 2.4 and saw no failures (after
applying patch #1168732, anyway).

Discussion

  • Kenneth J. Pronovici

    I am withdrawing this patch, because I'm sure it's out-of-date after 5 years, and I don't want to take responsibility for it if it is ever applied.

     
  • Kenneth J. Pronovici

    • status: open --> closed-out-of-date
     

Log in to post a comment.