More than a decade and a half ago, Kragen Javier Sitaker wrote a blog post isinstance() considered harmful, a lot of which I believe holds up pretty well today. It's well worth reading it in its entirety but the gist is that rather than testing a value against a specific type, you generally wish to check that a value confirms to a particular interface. Or if you prefer, using isinstance is imparting nominative typing in a language where duck typing is the convention.
I came across what I initially thought was a reasonable use of isintance and this post is about my attempts to remove the reliance on isinstance.
The case
Writing a web application often involves checking the contents of the current page for specific content. Usually in the form of CSS selectors, or simply text. I had written a simple method to check whether specific texts were contained in any elements matching a given CSS selector. For example, you may have some way of flashing messages and you want to check that after a given request the resulting web page contains the list of messages that you expect.
However, the general idea can be condensed to the more simple task of checking whether a list of texts are present with a main text. So the general idea is something like the following:
defcontains_texts(content,texts):fortintexts:iftnotincontent:returnFalsereturnTruetest_content="abcdefg qwerty"assertcontains_texts(test_content,['abcdefg','qwerty'])# Passes
This works fine, but this is in testing code, so we want to make sure that tests do not inadvertently pass. The problem here is that the texts argument is intended to be a list, or more generally, a container of some strings. The potential problem is that it is easy enough to make the mistake of calling this method with a single string. Strings are iterable, so unfortunately the following assertion passes:
test_content="abcdefg qwerty"assertcontains_texts(test_content,'gfedcba')# Passes
This is because each of the characters in the single string argument are themselves in the main content, although the string itself is not.
A potential fix for this is to use isinstance on the argument:
defisinstance_contains_texts(content,texts):ifisinstance(texts,str):returntextsincontentfortintexts:iftnotincontent:returnFalsereturnTruetest_content="abcdefg qwerty"assertisinstance_contains_texts(test_content,'abcdefg')# Passesassertnotisinstance_contains_texts(test_content,'gfedcba')# Passes
In this case we do the right thing if the method is called with a single string as the argument, but you could of course instead raise an error. So this basically solves our problem, but at the cost of using isinstance.
What happens if the content becomes a bytestring, and the input strings themselves are bytestrings:
assertisinstance_contains_texts(b'hello world',[b'hello',b'world'])# Passesassertisinstance_contains_texts(b'hello world',b'olleh')# Passes
We have the same problem as before. We could of course solve this by using if isintance(texts, str) or isinstance(texts, bytes), but that feels like we're not really solving the essence of the problem.
Without isinstance
So instead of using isinstance we could check for what interface is supported by the argument. If we want to check that it is a singleton argument then we would be looking for something supported by strings and bytestrings, but not by, lists, sets, or other general containers:
>>>str_and_bytestring=[xforxindir('')ifxindir(b'')]>>>stringy_but_not_listy=[xforxinstr_and_bytestringifxnotindir([])]>>>stringy_but_not_listy['__getnewargs__','capitalize','center','endswith','expandtabs','find','isalnum','isalpha','isdigit','islower','isspace','istitle','isupper','join','ljust','lower','lstrip','maketrans','partition','replace','rfind','rindex','rjust','rpartition','rsplit','rstrip','split','splitlines','startswith','strip','swapcase','title','translate','upper','zfill']
Okay so our test could be whether or not the texts argument has an attribute capitalize:
definterface_contains_texts(content,texts):ifhasattr(texts,'capitalize'):returntextsincontentfortintexts:iftnotincontent:returnFalsereturnTruetest_content="abcdefg qwerty"assertinterface_contains_texts(test_content,'abcdefg')# Passesassertnotinterface_contains_texts(test_content,'gfedcba')# Passesassertinterface_contains_texts(b'hello world',[b'hello',b'world'])assertnotinterface_contains_texts(b'hello world',b'olleh')
Sort of success, but this feels as if we're not really writing down what we mean. We don't really care if texts has a capitalize attribute at all. What we want to avoid is texts being a single argument that happens to be iterable. We can check which attributes containers such as lists and sets have that strings or bytestrings do not:
>>>list_and_set=[xforxindir([])ifxindir(set())]>>>str_or_bytestring=dir('')+dir(b'')>>>listy_but_not_string=[xforxinlist_and_setifxnotinstr_or_bytestring]>>>listy_but_not_string['clear','copy','pop','remove']
So we can check if the first argument has a 'clear' attribute:
definterface_contains_texts(content,texts):ifnothasattr(texts,'clear'):returntextsincontentfortintexts:iftnotincontent:returnFalsereturnTruetest_content="abcdefg qwerty"assertinterface_contains_texts(test_content,'abcdefg')# Passesassertnotinterface_contains_texts(test_content,'gfedcba')# Passesassertinterface_contains_texts(b'hello world',[b'hello',b'world'])# Passesassertnotinterface_contains_texts(b'hello world',b'olleh')# Passes
Unfortunately, you now cannot pass a generator, the following fails with a type error because interface_contains_texts attempts to check if the generator is in the given string.
assertinterface_contains_texts(test_content,(xforxintest_content.split()))
Unfortunately there is no attribute that is on a list, set, and generator that is not on a string or bytestring. But generators do have a close attribute so we could do:
definterface_contains_texts(content,texts):ifnothasattr(texts,'clear')andnothasattr(texts,'close'):...
This does feel close to what we want. We are saying "If the argument is not a list, set style container, or a generator, then we treat it as one singleton".
All of this could be avoided
Another way to do this would be to allow a variable number of arguments into the contains_texts function:
defvariable_args_contains_texts(content,*texts):fortintexts:iftnotincontent:returnFalsereturnTruetest_content="abcdefg qwerty"assertvariable_args_contains_texts(test_content,'abcdefg')# Passesassertnotvariable_args_contains_texts(test_content,'gfedcba')# Passesassertvariable_args_contains_texts(test_content,*['abcdefg','qwerty'])# Passesassertvariable_args_contains_texts(b'hello world',b'hello',b'world')# Passesassertnotvariable_args_contains_texts(b'hello world',b'olleh')# Passesassertvariable_args_contains_texts(test_content,*(xforxintest_content.split()))# Passes
This works for all our cases. You do have to star the argument if you already have a list or generator:
assertvariable_args_contains_texts(test_content,*['abcdefg','qwerty'])# Passesassertvariable_args_contains_texts(test_content,*(xforxintest_content.split()))# Passes
However, recall our original problem was that if you accidentally passed in a single string as the argument your test function may quietly, and erroneously, pass. However, if you forget the star to this function:
>>>variable_args_contains_texts(test_content,['abcdefg','qwerty'])Traceback(mostrecentcalllast):File"<stdin>",line1,in<module>File"<stdin>",line3,invariable_args_contains_textsTypeError:'in <string>'requiresstringasleftoperand,notlist
You get an error. That's quite alright with me, this will flag up immediately that I've written my test incorrectly and I can fix it immediately. Even if I had the original contains_texts and update it to this variable args version, when I re-run my test-suite it will let me know of any places I've forgotten to update the call.
Conclusion
Its debateable whether or not the interface_contains_texts version was better than the original isintance_contains_texts version. I prefer it because I feel it is a bit more general. I definitely prefer the eventual variable_args_contains_texts version. I guess that's the main conclusion for now, that checking your uses of isinstance may lead to a better implementation.
Although I was able to use variable arguments to the solve the problem in this case, there will obviously be cases where that fix does not apply. However, the main takeaway is that you don't necessarily have to swap your isinstance use for a hasattr use, thereby directly translating the use of isinstance. It could be that by having a slightly broader look at the general problem you're trying to solve, another solution is available.