Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
From: Andriy Kornatskyy <andriy.kornatskyy@live.com>
To: <steve+comp.lang.python@pearwood.info>, "python-list@python.org" <python-list@python.org>
Subject: RE: duck typing assert
Date: Fri, 9 Nov 2012 17:01:19 +0300
Importance: Normal
In-Reply-To: <509d06e7$0$29980$c3e8da3$5496439d@news.astraweb.com>
References: <mailman.3455.1352396166.27098.python-list@python.org>, <509c412d$0$29980$c3e8da3$5496439d@news.astraweb.com>, <mailman.3470.1352422891.27098.python-list@python.org>, <509d06e7$0$29980$c3e8da3$5496439d@news.astraweb.com>
Content-Type: text/plain; charset="windows-1251"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.3492.1352469747.27098.python-list@python.org>
Lines: 167
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:33025


1. In looks-like we check features of Foo (that may be superset) of what IF=
oo offers.

assert looks(Foo).like(IFoo)

2. We can check if Foo is limited to IFoo only:

assert looks(IFoo).like(Foo)

So it valid to have both asserts.

Thanks.

Andriy Kornatskyy


----------------------------------------
> From: steve+comp.lang.python@pearwood.info
> Subject: Re: duck typing assert
> Date: Fri=2C 9 Nov 2012 13:36:39 +0000
> To: python-list@python.org
>
> On Thu=2C 08 Nov 2012 18:00:58 -0700=2C Ian Kelly wrote:
>
> > On Thu=2C Nov 8=2C 2012 at 4:33 PM=2C Steven D'Aprano
> > <steve+comp.lang.python@pearwood.info> wrote:
> >> On Thu=2C 08 Nov 2012 20:34:58 +0300=2C Andriy Kornatskyy wrote:
> >>
> >>> People who come from strongly typed languages that offer interfaces
> >>> often are confused by lack of one in Python. Python=2C being dynamic
> >>> typing programming language=2C follows duck typing principal. It can =
as
> >>> simple as this:
> >>>
> >>> assert looks(Foo).like(IFoo)
> >>
> >> How very cute. And I don't mean that in a good way.
> >>
> >> Why is this a class with a method=2C instead of a function that takes =
two
> >> class arguments (plus any optional arguments needed)?
> >>
> >> looks_like(Foo=2C IFoo)
> >>
> >> is less "cute"=2C reads better to English speakers=2C and much more
> >> Pythonic. This isn't Java=2C not everything needs to be a class.
> >
> > I disagree. Does that test whether Foo looks like IFoo=2C or IFoo looks
> > like Foo?
>
> What's the difference? "Looks like" is a symmetric comparison=2C like
> "equal" and "almost equal"=2C but not "subset"=2C "less than" etc. If x l=
ooks
> like y=2C then necessarily y must look like x. If Katy Perry looks like
> Zooey Deschanel=2C then it stands to reason that Zooey Deschanel looks li=
ke
> Katy Perry. James Woods looks like Erwin Schroedinger=2C and Erwin
> Schroedinger looks like James Woods.
>
> http://tvrefill.com/wp-content/uploads/2010/12/zooey-deschanel.jpg
>
> http://cheezburger.com/6704400128
>
>
> So in that sense=2C looks(Spam).like(Ham) must always be the same as
> looks(Ham).like(Spam)=2C and the order of operators doesn't matter.
>
> But that's not what we want! And to his credit=2C that's not what Andriy
> Kornatskyy's code actually implements. The problem is with the name=2C
> which is actively misleading by suggesting a symmetrical comparison for
> one which is not symmetrical.
>
> Suppose we want to make a movie with Zooey Deschanel=2C but she's not
> available=2C so we want a replacement who is duck-type compatible with he=
r.
> The replacement doesn't need to be a Deschanel sister=2C but she does nee=
d
> to do *at least* everything Zooey can do. If she can do more=2C that's
> fine=2C but she can't do less.
>
> Since Katy Perry can do everything Zooey can do=2C PLUS she sings=2C we c=
an
> replace Zooey with Katy: Katy is duck-type compatible with Zooey. But we
> can't replace Katy with Zooey=2C because Zooey can't sing.[1]
>
> (I think... I really don't actually know if Zooey Deschanel can sing or
> not. Just go along with the example.)
>
> The point I am making is that "looks like" is not a good description for
> this function. "Looks like" must be symmetrical=2C but the function we
> actually want is not symmetrical. It is actually a "subset" type
> relationship: given "looks(Zooey).like(Katy)"=2C it checks that the publi=
c
> methods etc. of Zooey are a subset of the methods of Katy. That is=2C tha=
t
> instances of Katy can be used instead of instances of Zooey.
>
> Or is it the other way? Damned if I know. Let's find out:
>
> class Zooey:
> def act(self): pass
>
> class Katy:
> def act(self): pass
> def sing(self): pass
>
>
> py> looks(Zooey).like(Katy)
> __main__:2: UserWarning: 'sing': is missing.
> False
>
> I guessed wrong. The looks.like method as implemented tests that the
> right-hand size operand is a subset of the right-hand-side:
>
> py> looks(Katy).like(Zooey)
> True
>
>
> I argue that this is the wrong way around. (Even if it isn't the wrong
> way around=2C it certainly isn't clear or obvious which way you have to
> write the operands!)
>
> Consider this use-case:
>
> candidates =3D [Hilary=2C Jennifer=2C Katy]
> expected =3D looks(Zooey) # instantiate the looks class once only
> for actor in candidates:
> if expected.like(actor):
> make_movie_with(actor())
>
>
> That's much nicer and more efficient than the way you have to write it
> now:
>
> candidates =3D [Hilary=2C Jennifer=2C Katy]
> for actor in candidates:
> # instantiate the looks class every time we want to test another class
> if looks(actor).like(Zooey):
> make_movie_with(actor())
>
>
> So... it's a cute name=2C that sounds English-like. But it doesn't actual=
ly
> describe what the function does=2C it is wasteful for at least one useful
> use-case=2C and it's not clear which order you have to supply the two
> arguments.
>
>
> > looks(Foo).like(IFoo)=2C on the other hand=2C is crystal clear about wh=
ich
> > argument is which.
>
> I hope that by now you can see why I say that it is as clear as mud.
>
>
>
>
>
> [1] Some people might argue that neither can Katy Perry.
>
>
> --
> Steven
> --
> http://mail.python.org/mailman/listinfo/python-list
 		 	   		  =