I wouldn't use math.floor(x) != x

[KleinerNull]

Go the save round and just use isinstance(n, numbers.Number) or numbers.Complex, numbers.Real and and and. So you don't need to import the math module at all, which I think was your goal.

[mingrammer]

I did not know numbers module .. It's a very cool module which I really need.

I do very appreciate you. I'll update the every codebase which is using math.floor with numbers

Thank you!!

[KleinerNull]

Another thing is that you are artificially limiting your own code. Duck typing in dynamic languages has a purpose and can help you to avoid long lines of code because you rarely need to type check the stuff.

What is for example if someone code a complete new number type not based on the actual types but it has implemented the same or a very similar interface like an integer or a complex number. Why shouldn't abs not work on them?

Why should a vector class with arbitrary dimension not work with your function? Don't forget that all number types are vectors, just with specific dimensions and rule set. ;) If you never heard of this look out for Quaterions and Hyperr Complex Numbers.

This is actually very important in python. Think a while about this problem, maybe you can come up with an elegant, smart and DRY (don't repeat yourself) solution.

[mingrammer]

@KleinerNull You are right. I was do limiting my code by myself. So I decide that I should remove the type checking on functions which can accept various numeric types such as abs.

But, I should restrict the type on functions which can accept specific types, for exampe, the fibonacci function must only accept the integers.

[mingrammer]

I forgot the advantages of dynamic types, Thank you to remind it to me.

[KleinerNull]

But, I should restrict the type on functions which can accept specific types, for exampe, the fibonacci function must only accept the integers.

Why? For example range(1.6) will throw an error anyway, why raising an own error? Ask for forgiveness...

I forgot the advantages of dynamic types,

I've got the feeling you didn't understand my point. The idea was ad-hoc polymorphism. Look at how addition, subtraction or len is implemented. There is no long len function that have flow statements for all sequences, no this is handled in the individual class itself with implementing the __len__ function. The built-in len function just looks like this (simplified, without the error catching stuff):

def len(seq):
   return seq.__len__()

The same is happening for all the other stuff like the basic operations and also abs.

[mingrammer]

Ok I got it.
But .. that my first sentence means that I will add the type hint as following:

def fibonacci(n: int) -> int:
    # blah

without the custom Exception raising.

Because, with common sense, the fibonacci function can work only with integer. So, I just specify the input type hint to definition of function. I do not raise the custom error now with raise ValueError(...) in function body except raise ValueError('n must be >= 0') error which for validating the input.

Is it still weird? (Yes, I know that Ask for forgiveness... is a good principle, but I just give type hinting to function)

[mingrammer]

(Sorry for my english, I'm not a native speaker. Please understand)

[KleinerNull]

(Sorry for my english, I'm not a native speaker. Please understand)

Me too, me too. So don't worry :D

Is it still weird? (Yes, I know that Ask for forgiveness... is a good principle, but I just give type hinting to function)

Type hints are fine, but don't think about them as static typing like in other languages.

[mingrammer]

Sure, I know that :)

Anyway, thanks for pointing out the important things, it is very helpful to me. It was an interesting conversation :D