Thank you for all comments.

> It makes very good sense to say:
>
> duckmatch(IFoo).compare(Foo)

Since we do duck match of IFoo... but there is no `duck match`, there is `duck 
test`. I believe instead of `compare` is more readable with `equals`. Than it 
is more from mathematics - precise answer... that you can not guarantee at all 
in dynamic programming language. So it false to use such wording to reflect 
this check. We can only make an assumption that one looks like the other 
(similar)... with some limitation of cause... understanding what is `duck test`.

http://en.wikipedia.org/wiki/Duck_test

The intent is to make such language `construct` so it reads as English sentence 
that make sense, and not mandatory `pythonic` way (readability counts, java 
smokes aside).

is_similar(Foo).to(IFoo) # <= but we lost `duck test` sense here?

Words `looks` and `like` are coming from duck test and point also direction:

# 1
looks(Foo).like(IFoo, notice=['__len__'], ignore_funcs=['foo'], 
ignore_argspec['bar'])

English sentence equivalent: if functions in Foo looks like one in IFoo than, 
probably, IFoo can be replaced with Foo; notice to check __len__, it is safe to 
ignore function `foo` and arguments passed to `bar`.

# 2
looks(Foo, notice=['__len__'], ignore_funcs=['foo'], 
ignore_argspec['bar']).like(IFoo)

English sentence equivalent: while looking at Foo notice to check `__len__`, it 
is safe to ignore function `foo` and arguments passed to `bar`, than probably 
it like IFoo.

I think #1 is easier to understand once it is written. Thoughts?

Also construction looks(Foo).like(IFoo) points direction of check. It you need 
the two be replaceable you need two asserts:

assert looks(Foo).like(IFoo)
assert looks(IFoo).like(Foo)

Thanks.

Andriy Kornatskyy


----------------------------------------
> Date: Fri, 9 Nov 2012 17:14:49 +1100
> Subject: Re: duck typing assert
> From: ros...@gmail.com
> To: python-list@python.org
>
> On Fri, Nov 9, 2012 at 12:00 PM, Ian Kelly <ian.g.ke...@gmail.com> wrote:
> > looks(Foo).like(IFoo), on the other hand, is crystal clear about which
> > argument is which.
>
> I'm not so sure that it is, tbh. If you read it like an English
> sentence, it's clearly testing whether Foo matches the template in
> IFoo, but which are you more likely to do: test one class to see if it
> satisfies lots of templates, or test one template against every class
> you meet? I think probably the latter is, if not more likely than the
> former, at least sufficiently plausible as to create confusion. It
> makes very good sense to say:
>
> duckmatch(IFoo).compare(Foo)
>
> ie with the arguments the other way.
>
> ChrisA
> --
> http://mail.python.org/mailman/listinfo/python-list
                                          
-- 
http://mail.python.org/mailman/listinfo/python-list

Reply via email to