duck typing assert

[Andriy Kornatskyy]

There is sense for #2. Let me explain. There is basic IFoo implementation and improved Foo. While I switched to Foo, I still want to be as close to IFoo as possible, since there might be sense to switch to Foo2 later, which conform to IFoo.

Here is the problem: if I will not assert #2 potentially I will use some `features` that are not in IFoo, thus that breaks my code switching to Foo2 later.

That might not apply for 100% usability cases, just wanted to point that out as reasonable thing.

Thanks.

Andriy Kornatskyy


----------------------------------------
> Date: Sat, 10 Nov 2012 01:15:36 +1100
> Subject: Re: duck typing assert
> From: rosuav at gmail.com
> To: python-list at python.org
>
> On Sat, Nov 10, 2012 at 1:01 AM, Andriy Kornatskyy
> <andriy.kornatskyy at live.com> wrote:
> >
> > 1. In looks-like we check features of Foo (that may be superset) of what IFoo 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.
>
> You'll almost never need #2, but since there's no difference between a
> "class" and an "interface", it's perfectly legal to switch them
> around.
>
> But I would generally expect that unrecognized methods are never a
> problem (assuming they don't collide with anything) - that, as in
> Steven's example, it's fine to have an actor who can sing when you
> don't need her to. When you post job openings, you don't normally ask
> for someone with "5+ years Python experience and unable to program in
> REXX" [1]. You're checking for a minimum set of requirements.
>
> [1] Though I suppose you might ask for someone who's unable to program
> in Pascal. Might save you some hassle.
>
> ChrisA
> --
> http://mail.python.org/mailman/listinfo/python-list