return an object of a different class

Steven D'Aprano steve+comp.lang.python at
Mon Feb 21 18:33:03 EST 2011

On Mon, 21 Feb 2011 14:23:10 +0100, Jean-Michel Pichavant wrote:

> What is not legit, is to return different objects for which the caller
> has to test the type to know what attributes he can use.

Well, I don't know... I'm of two minds.

On the one hand, I find it *really annoying* when this happens:

>>>, text).group()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'NoneType' object has no attribute 'group'

The problem is that and re.match return None instead of a match-
object when they don't find anything. Perhaps they should return an empty 
match object?

But on the other hand, there is a well known failure mode caused by doing 

# Strip everything after a comment symbol.
offset = text.find("#")
text = text[:offset]

See the bug? If there's no # in the string, it drops the last character. 
The most insidious part of the bug is that you might not notice, if your 
strings end with whitespace. If str.find() returned None, at least you 
would get a nice TypeError as soon as you tried to use it as a integer 

So, it's not clear to me whether under *these* circumstances it's better 
to return a completely different type, which cannot possibly be mistaken 
for success, or a magic value of the same type.

(The third alternative is to raise an exception, and the unspeakably 
awful alternative is to have a single global error flag for the operation 
which must be checked.)


More information about the Python-list mailing list