[Python-projects] __init__ method from a non direct base class<logilab.astng.Yes object at 0xb7f8392c> is called

[Sylvain Thénault]

On Tuesday 21 November à 14:32, Amaury Forgeotdarc wrote:
> Sylvain Thénault wrote:
> > > We could also consider having a few shortcuts for some 
> > common cases, 
> > > such as --with-pygtk=2.6, if there is demand for this.
> > > 
> > > Sylvain, what is your opinion on this?
> > 
> > Hum, that sounds good to me. Idealy I would like pylint/astng 
> > to understand dynamically sys.path manipulation but as this 
> > is quite hard and I'm not even sure feasible in most cases, a 
> > solution like the one you propose would probably be the 
> > easiest and cleanest way to fix this asap. Maybe others on 
> > the list have an opinion or idea ?
> 
> Pylint cannot handle every possible python hack.
> My opinion is that this kind of problem should not be handled by pylint itself;
> Instead, there should be a way for e.g. gtk users to tell "yes, this code is too dynamic for Pylint to understand, let me help you".
> 
> Let me try with this particular example:
> If I register a Checker containing the following code:
>     def visit_callfunc(self, node):
>         for func in node.expr.infer():
>             if (isinstance(func, astng.Function)
>                 and func.name == "require"
>                 and func.root().name == "pygtk"):
> 
>                 assert isinstance(node.args[0], astng.Const)
>                 # Hack sys.path ourselves
>                 import pygtk
>                 pygtk.require(node.args[0].value)
> 
> Then analyzing code like 'import pygtk; pygtk.require("2.6")' would modify sys.path, and subsequent imports work correctly.
> (I did not test the code above, and don't know if it is correct at all.
> There are at least 2 problems: InferenceErrors are possible, and I should not compare packages and functions by name, but by their identity)

just a quick note : the way you use to compare the function "name" using
its "absolute name" (eg module name + function name) is the right way if
we don't want to consider that astng has an infinite cache (I had have a
request to restore the size limited cache a few days ago). I agree this
may cause some problems some times (which may probably resolved by
comparing package's file instead of name, but that's not clear how this
apply to your example).

I see also another problem: ensuring this checker is applied before
others depending on the sys.path manipulation. This could be handled
however by adjusting the checker's priority but we have to check that.
Maybe attributing a priority number to those kind of checker would help
avoiding conflicts in the future.
 
> But the important thing is that is seems possible to handle such cases *outside* pylint.
> They don't need a modification of the pylint engine.
> Instead, users (or package developers) could contribute their own "recipes" to help Pylint parse their code.

yep. Anyway I wouldn't have any objection to provide a checker
containing the most used recipes with the standard pylint distribution,
so users don't have to install extra stuff to analyze their pygtk
project for instance.

> We have done something similar for our own checkers: for every node like 'resource.getText("textID")', we patch the "infer()" function so that it fetches the "real" text from the translations database.
> 
> Astng (and its inference engine) is a wonderful tool. Let's use it!
> Of course this requires more documentation of its internals, and maybe export some convenience functions.

hey ! I'm glad to see someone else than me get the value of astng. Don't
hesitate to send feedback and feature requests for this project as well!
And of course simple docstring patches for the
class/methods/functions/whatever you had a hard time to understand
would be very valuable to the project ;)

-- 
Sylvain Thénault                               LOGILAB, Paris (France)
Formations Python, Zope, Plone, Debian:  http://www.logilab.fr/formations
Développement logiciel sur mesure:       http://www.logilab.fr/services
Python et calcul scientifique:           http://www.logilab.fr/science