Question

I’m not sure if I like Python’s dynamic-ness. It often results in me forgetting to check a type, trying to call an attribute and getting the NoneType (or any other) has no attribute x error. A lot of them are pretty harmless but if not handled correctly they can bring down your entire app/process/etc.

Over time I got better predicting where these could pop up and adding explicit type checking, but because I’m only human I miss one occasionally and then some end-user finds it.

So I’m interested in your strategy to avoid these. Do you use type-checking decorators? Maybe special object wrappers?

Please share…

Answer 1

forgetting to check a type

This doesn’t make much sense. You so rarely need to “check” a type. You simply run unit tests and if you’ve provided the wrong type object, things fail. You never need to “check” much, in my experience.

trying to call an attribute and
getting the NoneType (or any other)
has no attribute x error.

Unexpected None is a plain-old bug. 80% of the time, I omitted the return. Unit tests always reveal these.

Of those that remain, 80% of the time, they’re plain old bugs due to an “early exit” which returns None because someone wrote an incomplete return statement. These if foo: return structures are easy to detect with unit tests. In some cases, they should have been if foo: return somethingMeaningful, and in still other cases, they should have been if foo: raise Exception("Foo").

The rest are dumb mistakes misreading the API’s. Generally, mutator functions don’t return anything. Sometimes I forget. Unit tests find these quickly, since basically, nothing works right.

That covers the “unexpected None” cases pretty solidly. Easy to unit test for. Most of the mistakes involve fairly trivial-to-write tests for some pretty obvious species of mistakes: wrong return; failure to raise an exception.

Other “has no attribute X” errors are really wild mistakes where a totally wrong type was used. That’s either really wrong assignment statements or really wrong function (or method) calls. They always fail elaborately during unit testing, requiring very little effort to fix.

A lot of them are pretty harmless but if not handled correctly they can bring down your entire app/process/etc.

Um… Harmless? If it’s a bug, I pray that it brings down my entire app as quickly as possible so I can find it. A bug that doesn’t crash my app is the most horrible situation imaginable. “Harmless” isn’t a word I’d use for a bug that fails to crash my app.