Path: csiph.com!usenet.pasdenom.info!goblin2!goblin.stu.neva.ru!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: Terry Reedy <tjreedy@udel.edu>
Subject: Re: [Python-ideas] Message passing syntax for objects
Date: Tue, 19 Mar 2013 16:09:44 -0400
References: <CAMjeLr_dBCSL9VGjrW6wJjMDhLWFdxWqGWw+5MXTfo8+x9yfYw@mail.gmail.com> <5146B848.3040509@pearwood.info> <CAMjeLr9bH9nYpEeq8KjzHXmEXpuUgAjvWb3f2e7VR2sno=6Rkw@mail.gmail.com> <CAMjeLr9f1wmFTYh7ShQrzc-fo+Xa5DPG-LDULn2VnUbrBjEo-Q@mail.gmail.com> <1363643500.25746.YahooMailNeo@web184701.mail.ne1.yahoo.com> <CAMjeLr-m5uOW95zSHMO-18i81dH4Es0OCpte-HEO_rCmV=dpWA@mail.gmail.com> <1363663891.8351.YahooMailNeo@web184701.mail.ne1.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
In-Reply-To: <1363663891.8351.YahooMailNeo@web184701.mail.ne1.yahoo.com>
Cc: python-ideas@python.org
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.3534.1363723808.2939.python-list@python.org>
Lines: 47
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:41539

On 3/18/2013 11:31 PM, Andrew Barnert wrote:

> The idea that message passing is fundamentally different from method
> calling also turned out to be one of those strange ideas, since it
> only took a couple years to prove that they are theoretically
> completely isomorphic=E2=80=94and,

Since the isomorphism is so obvious, I somehow missed that Kay actually=20
thought that they were different. I suppose one could have different=20
(but isomorphic) mental image models.

For me, the problem with message passing, as usually though of, or=20
method calls in their usual syntax, is the breaking of symmetries such=20
as the commutivity of number addition. I think of 'a + b' as a message=20
to the interpreter, as supervisor of Python objects, to add a and b=20
together and give me the result. It turns out that a Python interpreter=20
does that by calling *either* a.__add__(b) or b.__add__(a) or possibly bo=
th.

The advantage of passing messages through a supervisor is that it can=20
'supervise' the process. The behavior with binary operators is one=20
example. The behavior of len(c) is another. If c.__len__ does not exist, =

(the programmers fault for calling len(c)), it raises one message. If=20
c.__len__ does not return a non-negative int, it raises another.

 > for that matter, they're both isomorphic to closures.

Translating into Python, does this refer to the fact that bound methods=20
are closures?

> In effect, your "objects" are just single-parameter functions, and
> your "messages" are the call operator.

The proposal seems to be that every object should have a=20
single-parameter call method that in turn calls a preferred, default=20
single-parameter named method.

For lists: def __call__(self, ob): self.append(ob)
For ints: def __call__(self, other): return self.__add__(other)

That seems useless as a general pattern.

--=20
Terry Jan Reedy