python already does raise a very clear and informative TypeError: unsupported operand type(s) for *: '<type of a>' and '<type of b>' without the if statements

nice

it's not clever at all, it's reducing run time significantly, there wasn't any notice on exceptions, if there was an indication that said the code had to account for different data types, then good job, but if it doesn't, it's just unnecesary

this isn't pythonic at all. you should rely on duck typing instead of checking for data type. let the __mul__ method raise an error instead of doing this, since returning None when the types aren't what you expect can lead to a lot of unexpected behavior.

Please use spoiler flag next time.

nice very nice !!!

Y'all saying it's overthinking the code... It's clever bro keep going!

Ah, I could have simplified my solution. Oh, well.

I don't think this is a good idea, this looks like overengineering the problem.

This will fail for all custom objects that implement a mul magic method, therefore supporting a multiply operation. @Voile has mentioned Fractions and Decimals, but string types can also be multiplied too.

Secondly, if there is a problem with one of the arguments, Python will throw a very nice and informative TypeError exception. You don't need to wrap it in two nested if-statements.

Thirdly, a failed isinstance() comparison will return False which will potentially hide an error and lead to unforeseen things.

I see what you tried to do, but remember that simple is better than complex ;)

and quadratic time complexity