Thoughts on using isinstance

[abcd]

In my code I am debating whether or not to validate the types of data
being passed to my functions. For example

def sayHello(self, name):
if not name:
rasie "name can't be null"
if not isinstance(name , str):
raise "name must be a string"
print "Hello " + name

Is the use of isinstance a "bad" way of doing things? is it a "heavy"
operation? for example, if I use this in each function validate input
will it slow things down a lot?

just curious how you might handle this type of situation (other than
not validating at all).

thanks

[Maxim Sloyko]

On Jan 24, 3:38 pm, "abcd" <codecr...@gmai l.comwrote:

In my code I am debating whether or not to validate the types of data
being passed to my functions. For example

def sayHello(self, name):
if not name:
rasie "name can't be null"
if not isinstance(name , str):
raise "name must be a string"
print "Hello " + name

Is the use of isinstance a "bad" way of doing things? is it a "heavy"
operation? for example, if I use this in each function validate input
will it slow things down a lot?

just curious how you might handle this type of situation (other than
not validating at all).

thanks

My opinion is that validation is generally good. However, you have to
make it not too strict.
For example, instead of

print "Hello " + name

you could have written

print "Hello " + str(name)

In this case requirement isinstance() will be too strict. The only
thing you have to check is that hasattr(name, "__str__") and
callable(name._ _str__)

In this case you can have validation, while at the same time enjoy full
flexibility of dynamic typing.

--
Maxim

[Steve Holden]

abcd wrote:

In my code I am debating whether or not to validate the types of data
being passed to my functions. For example

def sayHello(self, name):
if not name:
rasie "name can't be null"
if not isinstance(name , str):
raise "name must be a string"
print "Hello " + name

Is the use of isinstance a "bad" way of doing things? is it a "heavy"
operation? for example, if I use this in each function validate input
will it slow things down a lot?

just curious how you might handle this type of situation (other than
not validating at all).

thanks

The "Python way" is to validate by performing the operations you need to
perform and catching any exceptions that result. In the case of your
example, you seem to be saying that you'd rather raise your own
exception (which, by the way, should really be a subclass of Exception,
but we will overlook that) that relying on the interpreter to raise a
ValueError or a TypeError. Is there really any advantage to this? You
increase your code size and add *something* to execution time with
little real purpose.

People coming to Python after C++ or some similar language that allows
or requires parameter type declarations often don't feel comfortable
taking this direction to start with, but it works well for most of us.

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Blog of Note: http://holdenweb.blogspot.com

[Steve Holden]

abcd wrote:

In my code I am debating whether or not to validate the types of data
being passed to my functions. For example

def sayHello(self, name):
if not name:
rasie "name can't be null"
if not isinstance(name , str):
raise "name must be a string"
print "Hello " + name

Is the use of isinstance a "bad" way of doing things? is it a "heavy"
operation? for example, if I use this in each function validate input
will it slow things down a lot?

just curious how you might handle this type of situation (other than
not validating at all).

thanks

The "Python way" is to validate by performing the operations you need to
perform and catching any exceptions that result. In the case of your
example, you seem to be saying that you'd rather raise your own
exception (which, by the way, should really be a subclass of Exception,
but we will overlook that) that relying on the interpreter to raise a
ValueError or a TypeError. Is there really any advantage to this? You
increase your code size and add *something* to execution time with
little real purpose.

People coming to Python after C++ or some similar language that allows
or requires parameter type declarations often don't feel comfortable
taking this direction to start with, but it works well for most of us.

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Blog of Note: http://holdenweb.blogspot.com

[Duncan Booth]

"abcd" <co*******@gmai l.comwrote:

In my code I am debating whether or not to validate the types of data
being passed to my functions. For example

def sayHello(self, name):
if not name:
rasie "name can't be null"
if not isinstance(name , str):
raise "name must be a string"
print "Hello " + name

Is the use of isinstance a "bad" way of doing things? is it a "heavy"
operation? for example, if I use this in each function validate input
will it slow things down a lot?

just curious how you might handle this type of situation (other than
not validating at all).

For a start, don't raise strings as exceptions: only use instances of
Exception.

Now consider what your first test does: it throws an error if you pass in
an empty string. Perhaps you do want to check for that, in which case you
will need to test for it and throw an appropriate exception.

The first test also catches values such as None, 0 or []. Do you really
want to throw a different exception for sayHello(0) and sayHello(1)? It
seems a bit pointless, so the first test should just check against an empty
string and not against other false objects which would get caught by the
second test.

Now for the second test. It would probably be useful to say in the
exception which type was involved, not just that it wasn't a string.
An appropriate exception for these would be something like:

TypeError: cannot concatenate 'str' and 'int' objects

since that tells you both the types and the operation that failed. Delete
that second test altogether and you'll get an appropriate exception instead
of a string which hides all the information.

A good rule is if you want to hide exception information from the user do
it when displaying the exception not when raising it. That way you can get
at all the exception information available by changing one place in the
code instead of having to do it everywhere.

So your modified function should look like:

def sayHello(name):
if name=="":
raise ValueError("nam e can't be blank")
print "Hello "+name

(this is slightly different than your original in a few other ways: it will
accept unicode strings so long as they can be encoded in ascii, and its a
function as there isn't much point having a method which doesn't use self.)

[abcd]

The "Python way" is to validate by performing the operations you need to

perform and catching any exceptions that result. In the case of your
example, you seem to be saying that you'd rather raise your own
exception (which, by the way, should really be a subclass of Exception,
but we will overlook that) that relying on the interpreter to raise a
ValueError or a TypeError. Is there really any advantage to this? You
increase your code size and add *something* to execution time with
little real purpose.

People coming to Python after C++ or some similar language that allows
or requires parameter type declarations often don't feel comfortable
taking this direction to start with, but it works well for most of us.

regards
Steve

So instead of validating input I should just try and use the input as
if it was correct, and let python throw the errors?

[Neil Cerutti]

On 2007-01-24, abcd <co*******@gmai l.comwrote:

In my code I am debating whether or not to validate the types of data
being passed to my functions. For example

def sayHello(self, name):
if not name:
rasie "name can't be null"
if not isinstance(name , str):
raise "name must be a string"
print "Hello " + name

Is the use of isinstance a "bad" way of doing things? is it a
"heavy" operation? for example, if I use this in each function
validate input will it slow things down a lot?

just curious how you might handle this type of situation (other
than not validating at all).

Validation of parameters is an excellent idea, but *not*
validation of datatypes. The problem is that sayHello can
function properly with many more objects than just strings, if
you write it differently. The following version accepts any
iterable over strings.

def sayHello(self, name):
it = iter(name)
print "Hello", ''.join(it)

It still lacks validation. But to validate a name you will need
to conceive a set of regular strings that contains every name
you'd like to accept. Names probably aren't worth validating,
although you might reasonably reject a few things, like the empty
string.

--
Neil Cerutti

[Bruno Desthuilliers]

abcd a écrit :

In my code I am debating whether or not to validate the types of data
being passed to my functions. For example

def sayHello(self, name):
if not name:
rasie "name can't be null"
if not isinstance(name , str):
raise "name must be a string"
print "Hello " + name

Is the use of isinstance a "bad" way of doing things?

Mostly, yes. Python is dynamically typed (well, it's dynamic all the
way...), and fighting against the language is a bad idea.

Also, since the use of an object of non-compatible type would usually
raise an exception (and while we're at it, avoid using strings as
exceptions - better to use some Exception class), you don't actually
gain anything.

just curious how you might handle this type of situation (other than
not validating at all).

There are mostly 2 cases :
1/ you're getting data from the outside world. Here, you have to be
*very* careful, and you usually need more than simple validation. Good
news is that we have modules like FormEncode designed to handle this case.

2/ you're getting 'data' from within your Python program. If you
correctly applied 1/, whatever comes in should be ok - that is, unless
you have a programmer error !-). But then, you'll usually have a nice
exception and traceback (or better unit tests failures), so you can fix
the problem immediatly.

Now there are *a few* corner cases where it makes sens to check what has
been passed to a function - either because there are very strict and
stable requirements here, or because the function can accept different
kinds of objects, but needs to handle them in distinct ways.

MVHO is that the less code the better. As a matter of fact, trying to
'protect' your function, you introduced a syntax error, that would not
have been here if you had just wrote the simplest thing:

def say_hello(who):
print "Hello", who

My 2 cents...

[Steve Holden]

abcd wrote:

>The "Python way" is to validate by performing the operations you need to
perform and catching any exceptions that result. In the case of your
example, you seem to be saying that you'd rather raise your own
exception (which, by the way, should really be a subclass of Exception,
but we will overlook that) that relying on the interpreter to raise a
ValueError or a TypeError. Is there really any advantage to this? You
increase your code size and add *something* to execution time with
little real purpose.

People coming to Python after C++ or some similar language that allows
or requires parameter type declarations often don't feel comfortable
taking this direction to start with, but it works well for most of us.

regards
Steve

So instead of validating input I should just try and use the input as
if it was correct, and let python throw the errors?

Yes. This approach is often referred to as BTAFTP (better to ask
forgiveness than permission), as opposed to the LBYL (look before you
leap) approach that your original email inquired about.

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Blog of Note: http://holdenweb.blogspot.com

[abcd]

Well my example function was simply taking a string and printing, but
most of my cases would be expecting a list, dictionary or some other
custom object. Still propose not to validate the type of data being
passed in?

Thanks.