Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
From: Andriy Kornatskyy <andriy.kornatskyy@live.com>
To: <ian.g.kelly@gmail.com>, "python-list@python.org" <python-list@python.org>
Subject: RE: duck typing assert
Date: Thu, 8 Nov 2012 22:29:10 +0300
Importance: Normal
In-Reply-To: <CALwzidkt5YVzw1bUbbdXUVVKCfBrLch1GsRUU6TiQjecM0qgEg@mail.gmail.com>
References: <DUB117-W186195307307D8E0A51FF891690@phx.gbl>, <CALwzidkt5YVzw1bUbbdXUVVKCfBrLch1GsRUU6TiQjecM0qgEg@mail.gmail.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.3460.1352402952.27098.python-list@python.org>
Lines: 118
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:32973


Ian=2C

Thank you for the comments.

There is definitely a room for improvement=2C however there are limits. One=
 of them is related to decorator that replaces decorated method arguments w=
ith something like *args=2C **kwargs. Here is an example.

def x():
=A0=A0=A0 def decorate(m):
=A0=A0=A0=A0=A0=A0=A0 def x(*args=2C **kwargs):
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 pass
=A0=A0=A0=A0=A0=A0=A0 return x
=A0=A0=A0 return decorate

class Foo(object):

=A0=A0=A0 @x
=A0=A0=A0 def bar(self=2C a):
=A0=A0=A0=A0=A0=A0=A0 pass

Another one challenge is related to inheritance=2C or even more complex cas=
e: multiple inheritance. I do not believe there is a need to scan whole hie=
rarchy=2C better apply checks separately=2C the assert will be more readabl=
e.

class IFoo(object):
=A0=A0=A0 def foo(self):
=A0=A0=A0=A0=A0=A0=A0 pass

class IBar(IFoo):
=A0=A0=A0 def bar(self):
=A0=A0=A0=A0=A0=A0=A0 pass

class Bar(IBar):
=A0=A0=A0 def foo(self):
=A0=A0=A0=A0=A0=A0=A0 pass

=A0=A0=A0 def bar(self):
=A0=A0=A0=A0=A0=A0=A0 pass

assert looks(Bar).like(IBar)
assert looks(Bar).like(IFoo)


I agree=2C special methods __?__ should not be considered private... but wh=
at is right: know which one are special (how about some custom? e.g. __ctx_=
_) or enforce check for it by explicitly asking for such check?

# 1
assert looks(Foo).like(IFoo=2C notice=3D['__len__'])
# 2
assert looks(Foo=2C notice=3D['__len__']).like(IFoo)

I believe if IFoo.foo is decorated as property=2C it must remain property=
=2C otherwise you need exclude it from checks=2C thus this way you pay code=
 reviewer attention to that.

Thanks.

Andriy Kornatskyy


----------------------------------------
> From: ian.g.kelly@gmail.com
> Date: Thu=2C 8 Nov 2012 11:34:45 -0700
> Subject: Re: duck typing assert
> To: python-list@python.org
>
> On Thu=2C Nov 8=2C 2012 at 10:30 AM=2C Andriy Kornatskyy
> <andriy.kornatskyy@live.com> wrote:
> >
> > People who come from strongly typed languages that offer interfaces oft=
en are confused by lack of one in Python. Python=2C being dynamic typing pr=
ogramming language=2C follows duck typing principal. It can as simple as th=
is:
> >
> > assert looks(Foo).like(IFoo)
> >
> > The post below shows how programmer can assert duck typing between two =
Python classes:
> >
> > mindref.blogspot.com/2012/11/python-duck-typing-assert.html
> >
> > Comments or suggestions are welcome.
>
> Overall=2C it looks potentially useful to me. Looking over the
> wheezy.core.introspection source=2C it appears to ignore special method
> names. For example=2C if you do:
>
> class IFoo(object):
> def __len__(self):
> pass
>
> class Foo(object):
> pass
>
> assert looks(Foo).like(IFoo)
>
> I would expect this to fail=2C but judging from the code it would not=2C
> as it ignores all names starting with '_'. That makes some sense for
> private names (but on the other hand=2C why would you declare private
> names in an interface unless you want to enforce their presence?)=2C but
> names like __len__ should not be considered private.
>
> Another comment I have is on properties=2C and descriptors in general.
> Does this allow something declared as a property to be implemented as
> a simple class attribute=2C and vice versa? Or can something declared
> as a property be implemented with some custom descriptor class? I
> think the answer is "no" to both=2C as the check it performs is
> "t2.__class__ is not t.__class__". I assert though that in general
> the type of a descriptor (that is not a simple class attribute) is not
> as important in duck testing as its API -- and all descriptors have
> basically the same API of __get__=2C __set__=2C and __delete__.
> --
> http://mail.python.org/mailman/listinfo/python-list
 		 	   		  =