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: ros...@gmail.com > To: python-list@python.org > > On Sat, Nov 10, 2012 at 1:01 AM, Andriy Kornatskyy > <andriy.kornats...@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 -- http://mail.python.org/mailman/listinfo/python-list
