From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Yuri Khan Newsgroups: gmane.emacs.devel Subject: Re: Generalizing find-definition Date: Tue, 4 Nov 2014 09:52:28 +0700 Message-ID: References: <20141102151524.0d9c665c@forcix> <20141102172944.0f7944e3@forcix> <20141103084433.12117c03@forcix> <20141103192853.2702fe7a@forcix> <20141103215526.28edeb27@forcix> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1415069571 6364 80.91.229.3 (4 Nov 2014 02:52:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 4 Nov 2014 02:52:51 +0000 (UTC) Cc: Stefan Monnier , Emacs developers To: Jorgen Schaefer Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 04 03:52:44 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XlUEc-0005k0-PI for ged-emacs-devel@m.gmane.org; Tue, 04 Nov 2014 03:52:42 +0100 Original-Received: from localhost ([::1]:38258 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlUEc-0001ug-BO for ged-emacs-devel@m.gmane.org; Mon, 03 Nov 2014 21:52:42 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60761) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlUEQ-0001ub-IQ for emacs-devel@gnu.org; Mon, 03 Nov 2014 21:52:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XlUEP-0000Wi-Ef for emacs-devel@gnu.org; Mon, 03 Nov 2014 21:52:30 -0500 Original-Received: from mail-ie0-x22d.google.com ([2607:f8b0:4001:c03::22d]:63730) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlUEP-0000WS-9N for emacs-devel@gnu.org; Mon, 03 Nov 2014 21:52:29 -0500 Original-Received: by mail-ie0-f173.google.com with SMTP id tr6so6675032ieb.18 for ; Mon, 03 Nov 2014 18:52:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=6ZatMXWBL40LB9arO0sEqc3LWgLEfU9ZPOB5pXZTFC4=; b=IBq3ici6ffICBimFGxsxZqDbs2hCtLZ4/cFnQara/ewfBhOrK6Siqf2SaQQ5q3xAbo 0JIVV5l4su12To3UTh32F7LMVDYppGcBzEJVjzYpAaqU0vfzbg+Ch3DY+4prroK9ghOT 0aMuegQFv9hOwhVRZFS45ohdvW/TLIwHtznYaIADLjl8/G7/F92Dj7wVYFIjPiPAmDM/ vlTSmxfaD5u5XBe+MWOFmqZMPH5MzLXcsjVtFbj2JSg5d+aNag4iDsxJa9ot3a5qhcuI Mkro0X87rbOdpg58aAd2UJLGEQN9P5+XzQSQZDqDp7asdNnqEWZW68YVOdLhlfgRfiu+ +x6A== X-Received: by 10.43.164.200 with SMTP id mt8mr29185974icc.22.1415069548675; Mon, 03 Nov 2014 18:52:28 -0800 (PST) Original-Received: by 10.107.48.3 with HTTP; Mon, 3 Nov 2014 18:52:28 -0800 (PST) In-Reply-To: <20141103215526.28edeb27@forcix> X-Google-Sender-Auth: 6lC-n20E_xOnkkxnQ40QPcVL18w X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c03::22d X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:176330 Archived-At: On Tue, Nov 4, 2014 at 2:55 AM, Jorgen Schaefer wrote: > Consider a piece of code like this: > > from foo import Foo > > bar =3D 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 =3D 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, =E2=80=9CFind definition=E2=80=9D 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.