I notice there is no error-checking, so my program would have problems with incorrect input

Lack of error checking, eg duck typing is generally approved of and preferred in python. Surely there are good cases to use input checking, but generally duck-typing is preferred.

I suspect this preference in python is mostly due to all the "primitives" actually being first class objects: int, str, bool. They all have values, methods, and identities.

Besides, type checking often just gets in the way of your users. Say I use a integer like class that is tied to an active record or has other features that make it better to work with in my application, a type check is just a barrier to entry that maybe I don't care to hoop-jump for. I use my integer class in place of integers everywhere in my app just fine, without type checking, your code may/would have optimistically run with whatever given object and worked just fine too. Functions that quit just because say an input object dosen't identify as an integer are just plain annoying.

Of course other suttle and cleaver advantages could be leveraged too. A caller could cleverly integrate with your function in rich ways, passing an impersonated integer-compatible object with valuable performance/analytics tracking and/or whatever else might be needed for a proper unit test, or an object that just knows that when certain math is applied, that it should update a progress bar. Whatever odd edge case matters, python so often has an in. The "we're all consenting adults" dogma that dosent sheild any part of the rumtime from good (or bad) ideas, lets the analytics engineer harmlessly track the core components, and let's the performance engineer substitute in-place code with bootstrapping and wrappers that hold over until something can be rearchitected.

If you are to pursue type checking I would at most suggest catching the kind of operational arithmetic error that incompatible types would cause and raise instead a type error, or a specific-to-your-module exception that probably extends typeerror when the input has produced an apparent failure condition.

The value in extending a module specific exception is that it gives any caller a sure way to catch errors only from your module, without giving up valuable semantics or messages.

I notice there is no error-checking, so my program would have problems with incorrect input

Lack of error checking, eg duck typing is generally approved of and preferred in python. Surely there are good cases to use input checking, but generally duck-typing is preferred.

I suspect this preference in python is mostly due to all the "primitives" actually being first class objects: int, str, bool. They all have values, methods, and identities.

Besides, type checking often just gets in the way of your users. Say I use a integer-like class that is tied to an active record or has other features that make it better to work with in my application; a type check is just a barrier to entry that maybe I don't care to hoop-jump for. I use my integer class in place of integers everywhere in my app just fine, without type checking; your code may/would have optimistically run with whatever given object and worked just fine too. Functions that quit just because say an input object doesn't identify as an integer are just plain annoying.

Of course other subtle and clever advantages could be leveraged too. A caller could cleverly integrate with your function in rich ways, passing an impersonated integer-compatible object with valuable performance/analytics tracking and/or whatever else might be needed for a proper unit test, or an object that just knows that when certain maths is applied, that it should update a progress bar. Whatever odd edge case matters, Python so often has an "in". The "we're all consenting adults" dogma that doesn't shield any part of the runtime from good (or bad) ideas, lets the analytics engineer harmlessly track the core components, and lets the performance engineer substitute in-place code with bootstrapping and wrappers that hold over until something can be re-architected.

If you are to pursue type checking I would at most suggest catching the kind of operational arithmetic error that incompatible types would cause and raise instead a type error, or a specific-to-your-module exception that probably extends TypeError, when the input has produced an apparent failure condition.

The value in extending a module-specific exception is that it gives any caller a sure way to catch errors only from your module, without giving up valuable semantics or messages.