Re: Generalizing find-definition

[Yuri Khan <yuri.v.khan@gmail.com>]

On Tue, Nov 4, 2014 at 2:55 AM, Jorgen Schaefer <forcer@forcix.cx> wrote:

> Consider a piece of code like this:
>
>     from foo import Foo
>
>     bar = Foo()
>     bar.baz_|_
>
> M-. should go to the definition of the attribute baz of the class Foo.
> But the obvious "identifier at point" is "bar.baz", which by itself
> does not have any relationship to said method without the assignment
> "bar = Foo()", which by itself is also not meaningful without the
> import statement. The only single string that reliably would allow to
> find the correct definition would be "foo.Foo.baz", but I do not think
> that anyone would consider that to be "the identifier at point" here.s

How are you solving (or going to solve) the problem of dynamic/duck typing?

Consider:

```python
def get_content(file_like):
    return file_like.read_|_()
```

Here, in a function that accepts any file-like object, “Find
definition” for read() might mean might mean file.read, or
StringIO.read, or zipfile.ZipExtFile.read, or a read() method of any
of a multitude classes defined in various libraries.

Showing all definitions of read() method of all classes defined in the
transitive closure of modules imported by the main program is
moderately easy but not helpful to the user (e.g. because some classes
are never passed in and their read() implements a different semantic).

Determining which exact subset of read() methods can be available at
the given location in code, I suspect, amounts to solving the Halting
Problem.