Chris Angelico <ros...@gmail.com>:
> On Tue, Jun 2, 2015 at 5:44 PM, Rustom Mody <rustompm...@gmail.com> wrote:
>> 1 ∈ all these
>> Are the '∈'s here same? Similar?
>
> Yes, they are. Every one of them is asserting (or asking, depending on
> your point of view) whether or not the instance to its left is a
> member of the set to its right. The sets on the right are all
> different, but the set membership operation is identical.
That is the risk of taking classes into Python. People start to obsess
about membership and ontological relationships. I think you should use
the type() function only for troubleshooting and isinstance() virtually
never.
I think objects should be understood only through their operational
semantics, ie, their methods. It doesn't matter what an object is; what
matters is what it does. Don't test it, just call it.
Yeah, I'm preaching to the choir:
Alex Martelli made an early (2000) use of the term in a message to
the comp.lang.python newsgroup:
In other words, don't check whether it IS-a duck: check whether
it QUACKS-like-a duck, WALKS-like-a duck, etc, etc, depending on
exactly what subset of duck-like behaviour you need to play your
language-games with.
<URL: http://en.wikipedia.org/wiki/Duck_typing>
Marko
PS I have written code that violates my stated rule. For example, an
argument could be a string or a list of strings for convenience.
However, this kind of testing should not be performed on anything
created with the "class" keyword. IOW, some types *are* more primitive
than others -- in our minds and in practical use.
--
https://mail.python.org/mailman/listinfo/python-list
