Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>To summarize the contents of other (already good!) answers, <code>isinstance</code> caters for inheritance (an instance of a derived class <em>is an</em> instance of a base class, too), while checking for equality of <code>type</code> does not (it demands identity of types and rejects instances of subtypes, AKA subclasses).</p> <p>Normally, in Python, you want your code to support inheritance, of course (since inheritance is so handy, it would be bad to stop code using yours from using it!), so <code>isinstance</code> is less bad than checking identity of <code>type</code>s because it seamlessly supports inheritance.</p> <p>It's not that <code>isinstance</code> is <em>good</em>, mind you—it's just <em>less bad</em> than checking equality of types. The normal, Pythonic, preferred solution is almost invariably "duck typing": try using the argument <em>as if</em> it was of a certain desired type, do it in a <code>try</code>/<code>except</code> statement catching all exceptions that could arise if the argument was not in fact of that type (or any other type nicely duck-mimicking it;-), and in the <code>except</code> clause, try something else (using the argument "as if" it was of some other type).</p> <p><code>basestring</code> <strong>is</strong>, however, quite a special case—a builtin type that exists <strong>only</strong> to let you use <code>isinstance</code> (both <code>str</code> and <code>unicode</code> subclass <code>basestring</code>). Strings are sequences (you could loop over them, index them, slice them, ...), but you generally want to treat them as "scalar" types—it's somewhat incovenient (but a reasonably frequent use case) to treat all kinds of strings (and maybe other scalar types, i.e., ones you can't loop on) one way, all containers (lists, sets, dicts, ...) in another way, and <code>basestring</code> plus <code>isinstance</code> helps you do that—the overall structure of this idiom is something like:</p> <pre><code>if isinstance(x, basestring) return treatasscalar(x) try: return treatasiter(iter(x)) except TypeError: return treatasscalar(x) </code></pre> <p>You could say that <code>basestring</code> is an <em>Abstract Base Class</em> ("ABC")—it offers no concrete functionality to subclasses, but rather exists as a "marker", mainly for use with <code>isinstance</code>. The concept is obviously a growing one in Python, since <a href="http://www.python.org/dev/peps/pep-3119/" rel="noreferrer">PEP 3119</a>, which introduces a generalization of it, was accepted and has been implemented starting with Python 2.6 and 3.0.</p> <p>The PEP makes it clear that, while ABCs can often substitute for duck typing, there is generally no big pressure to do that (see <a href="http://www.python.org/dev/peps/pep-3119/#abcs-vs-duck-typing" rel="noreferrer">here</a>). ABCs as implemented in recent Python versions do however offer extra goodies: <code>isinstance</code> (and <code>issubclass</code>) can now mean more than just "[an instance of] a derived class" (in particular, any class can be "registered" with an ABC so that it will show as a subclass, and its instances as instances of the ABC); and ABCs can also offer extra convenience to actual subclasses in a very natural way via Template Method design pattern applications (see <a href="http://en.wikipedia.org/wiki/Template_method_pattern" rel="noreferrer">here</a> and <a href="http://www.catonmat.net/blog/learning-python-design-patterns-through-video-lectures/" rel="noreferrer">here</a> [[part II]] for more on the TM DP, in general and specifically in Python, independent of ABCs).</p> <p>For the underlying mechanics of ABC support as offered in Python 2.6, see <a href="http://docs.python.org/library/abc.html" rel="noreferrer">here</a>; for their 3.1 version, very similar, see <a href="http://docs.python.org/3.1/library/abc.html" rel="noreferrer">here</a>. In both versions, standard library module <a href="http://docs.python.org/3.1/library/collections.html#module-collections" rel="noreferrer">collections</a> (that's the 3.1 version—for the very similar 2.6 version, see <a href="http://docs.python.org/library/collections.html#module-collections" rel="noreferrer">here</a>) offers several useful ABCs.</p> <p>For the purpose of this answer, the key thing to retain about ABCs (beyond an arguably more natural placement for TM DP functionality, compared to the classic Python alternative of mixin classes such as <a href="http://docs.python.org/library/userdict.html?highlight=userdict#UserDict.DictMixin" rel="noreferrer">UserDict.DictMixin</a>) is that they make <code>isinstance</code> (and <code>issubclass</code>) much more attractive and pervasive (in Python 2.6 and going forward) than they used to be (in 2.5 and before), and therefore, by contrast, make checking type equality an even worse practice in recent Python versions than it already used to be.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload