Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #33008

RE: duck typing assert

Show all headers | View raw

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: rosuav@gmail.com
> To: python-list@python.org
>
> On Fri, Nov 9, 2012 at 12:00 PM, Ian Kelly <ian.g.kelly@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
 		 	   		  

Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

duck typing assert‏ Andriy Kornatskyy <andriy.kornatskyy@live.com> - 2012-11-08 20:34 +0300
  Re: duck typing assert‏ Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-11-08 23:33 +0000
    Re: duck typing assert Ian Kelly <ian.g.kelly@gmail.com> - 2012-11-08 18:00 -0700
      Re: duck typing assert Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-11-09 13:36 +0000
        RE: duck typing assert Andriy Kornatskyy <andriy.kornatskyy@live.com> - 2012-11-09 17:01 +0300
        Re: duck typing assert Chris Angelico <rosuav@gmail.com> - 2012-11-10 01:15 +1100
        RE: duck typing assert Andriy Kornatskyy <andriy.kornatskyy@live.com> - 2012-11-09 17:37 +0300
    Re: duck typing assert Chris Angelico <rosuav@gmail.com> - 2012-11-09 17:14 +1100
    RE: duck typing assert Andriy Kornatskyy <andriy.kornatskyy@live.com> - 2012-11-09 13:26 +0300
    RE: duck typing assert "Prasad, Ramit" <ramit.prasad@jpmorgan.com> - 2012-11-09 17:37 +0000
    RE: duck typing assert Andriy Kornatskyy <andriy.kornatskyy@live.com> - 2012-11-09 20:55 +0300

csiph-web