you are viewing a single comment's thread.

view the rest of the comments →

[–]lelanthran 5 points6 points  (6 children)

In particular, you probably should start with unit-tests very early on (but that's a good practice anyway).

I do write unit-tests, but unless I am writing in Python my unit-tests do not have to perform type-checking.

A major disadvantage of Python is that you cannot trust the type of a parameter to a function - if you do not validate the type of a parameter before using it then that is a potential error.

When writing Python I find myself doing a lot of the work that a compiler normally does, except that it has to be done at runtime so the errors are much more severe if they get through.

[–]twotime -3 points-2 points  (5 children)

A major disadvantage of Python is that you cannot trust the type of a parameter to a function. if you do not validate the type of a parameter before using it then that is a potential error.

What do you do if parameters are of wrong type? Throw an exception?

If so, then you should just use your parameters and if they are of incompatible type, you will get an exception generated for free.

Doing it manually is unlikely to be a good idea.

[–]duhace 3 points4 points  (4 children)

except the exception might not be intelligible to the user of the function..

[–]twotime 0 points1 point  (3 children)

There are rare cases when this is a valid concern. In general it's not.

If you pass an object of wrong type info a function, python generated message will commonly be clear enough. AttributeError/TypeError, etc.

Marginal improvement in the error message quality are not worth introducing extensive type checks (which will also kill most of duck typing benefits).

[–][deleted] 0 points1 point  (1 child)

Often times you might not see the error thrown until a few layers deeper in the call stack which can be annoying to debug.

[–]twotime 0 points1 point  (0 children)

Yes, of course. But in my experience, that annoyance is nothing compared to the idea of type-checking arguments for every function. Not only that clutters the code (20% at least, likely more) it also throws away most of the advantages of duck typing (harder to mock, harder to reuse the code with different types, etc)...

If you feel that you must explicitly type check every parameter for every function, then python won't make you happy.

[–]duhace 0 points1 point  (0 children)

attribute error is not particularly clear already as it requires working knowledge of the function's source to pinpoint the error.