Le 6 octobre 2010 04:37, Sylvain Thénault <[email protected]> a
écrit :

> On 05 octobre 21:12, Marc-Antoine Ruel wrote:
> > Le 5 octobre 2010 17:14, Maarten ter Huurne <[email protected]> a
> écrit
> > :
> >
> > > On Tuesday 05 October 2010, Marc-Antoine Ruel wrote:
> > >
> > > > And that's the problem I see, astng sees "isinstance" as a normal
> > > > CallFunc() node instead of a specialized node (?)
> > >
> > > "isinstance" is a built-in function, not a keyword:
> > >
> > > >>> isinstance
> > > <built-in function isinstance>
> > >
> > > So I think astng is correct in returning a CallFunc node for it.
> > >
> > > Maybe you can check for the function name being "isinstance" and the
> > > function module being "__builtin__"?
> > >
> >
> > My bad, you are right. I'm just no sure where the pattern matching code
> > should go, basically I want to match the tree for this layout:
> >
> >         Assert()
> >             test =
> >             CallFunc()
> >                 func =
> >                 Name(isinstance)
> >                 args = [
> >                 Name(x)
> >                 Name(A)
> >                 ]
> >                 starargs =
> >                 kwargs =
> >
> > In that case, Name(isinstance) needs to confirm it's the __builtin__
> version
> > (how?) and Name(A) must be resolved to the type. The shortest hack would
> be
> > to conceptually replace this form with the equivalent inference from "x =
> > A()".
> >
> > I wonder where this check should be.
>
> I'm afraid all this would require some changes in astng to store such
> inference
> tips. Currently, type inference works by navigating into the ast, also
> there
> is no notion of "variable x". In the code
>
>  1. assert isinstance(x, A)
>  2. x.method()
>
> astng sees both statements as unrelated (it only knows nodes of the ast).
> One
> can use node.infer() (where node is a Name node for instance) to try to
> resolve
> its possible values. This works basically by filtering assigments and
> resolving
> them until we reach a "final" node like a typed constant, a class instance,
> etc.
>

That's where I was thinking about to hook up; basically having a function
similar to astng.interence.infer_ass() for nodes.Assert.infer() that would
match for the very specific subset of self.test==CallFunc(instance, Name,
Name).



> So to make this work we should first store type annotation (extracted from
> detected calls to isinstance as proposed, python 3 annotations... during
> astng
> building step), then detect and use them when infering.
>
> You should first take a look at LocalsDictNodeNG / scope  lookup.
>

>From what I understand, a change would be required in
node_classes.LookupMixIn._filterstmts().


If you dig you'll see that indeed astng has a somewhat "flat" representation
> and is not well able to handle data flow...
>

I assume that would be a huge amount work to improve this. :/

M-A
_______________________________________________
Python-Projects mailing list
[email protected]
http://lists.logilab.org/mailman/listinfo/python-projects

Reply via email to