Typeguard provides this functionality: https://typeguard.readthedocs.io/en/latest/userguide.html It's not perfect but that's because runtime type hints have lots of restrictions on what can be reasoned about them. But for simple and common cases it works very well. -- Damian (he / him) On Sun, Apr 25, 2021 at 9:38 AM Richard Damon <Richard@damon-family.org> wrote:

...

Think it like this. We have this code in Python :-

def add(a, b): return a + b

Here we are taking two arguments a, b and then returning a + b. But we can pass in instance of any class like str, int, float, dict, user-defined class, etc. But we only want to add int here. Here we can modify it to be,

def add(a, b): if type(a) == int and type(b) == int: return a +b raise Exception("Error")

In this example it's pretty easy to check if the arguments are int. But in real world programs as the functions become bigger and bigger it's very difficult to check arguments using an if statement. Therefore why not let

On 4/25/21 9:09 AM, Shreyan Avigyan wrote: the user specify what parameter types are gonna be? Like,

...

def add(int a, int b): return a + b

If instance of a different class is passed in then raise a TypeError

perhaps? If parameter types are not given then let the parameter accept any kind of class instance.

...

This kind of functionality will minimize a lot of if statements related

to parameter types and arguments.

...

Thanking you, With Regards

Well, in Python with type annotations that would be spelled:

def add(a: int, b: int):

return a + b

but the one difference is that, at least by default, that requirement is advisorary only. You can run a static type checker like mypy at it will see if it can deduce a case where you pass a non-int to the function.

You could also import a module into your module that will actually do the check at run-time (I don't know of one, but there probably is one) maybe needing the function to be decorated to request the type checking.

-- Richard Damon

_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/7DCIKC... Code of Conduct: http://python.org/psf/codeofconduct/

On Mon, Apr 26, 2021 at 4:19 AM Shreyan Avigyan <pythonshreyan09@gmail.com> wrote:

I am aware of all those libraries that allows us to type check. But it would be nice to have this feature built-in. I'm not talking about modifying type annotation but introducing a new feature. Like,

def add(int a, int b): return a + b

If type is not provided then take in any parameter types. Like,

def example(c): print(c)

Why? Type annotations already exist. You're asking for something that requires brand new syntax and can already be done. Instead of writing it as if it's C, try writing it like this: @type_check def add(a: int, b: int) -> int: return a + b (I took the liberty of adding a return value annotation as well.) There are several existing libraries that can provide a decorator to do these sorts of run-time checks, or you can write your own. By the way: If you're writing checks like this, you have bigger problems than syntax. # Don't do this def add(a, b): if type(a) == int and type(b) == int: return a +b raise Exception("Error") Instead, all type checks should use isinstance, so that subclasses are allowed: def add(a, b): if not isinstance(a, int) or not isinstance(b, int): raise TypeError("Arguments must be integers") return a + b But it is far better, in most situations, to allow your function to be used by more types. Do you REALLY need to require that the numbers be integers, or is it okay for them to be other types of number? What if they're floats or Fractions that happen to be integers (eg 25.0 or 25/1)? Forcing precise types makes your function less useful in situations when it otherwise could be exactly what someone wants. ChrisA

On Mon, Apr 26, 2021 at 4:58 AM Shreyan Avigyan <pythonshreyan09@gmail.com> wrote:

First of all the use case is when for example we have UserDefined class and my function or another class can only handle instances of the UserDefined class. Second of all why not add a built-in type check decorator then?

What if it's a subclass of that class, though? If you check if the type is equal to something, you'd unnecessarily reject subclasses. And, because MOST programs don't need that sort of checking. It's completely unnecessary. Just write your code without checks, and let people call your function with any object that is suitable - that's the essence of duck typing, and it's far easier to work with. Don't write the checking code, and that way, it can't be buggy; as a bonus, your function is more flexible. ChrisA

On 4/25/21 3:08 PM, Shreyan Avigyan wrote:

Thanks for clarifying. And I agree with you. Not writing checking code will make the function more flexible.

Thanking you, With Regards

My experiance is that the type annotaions let my IDE warn me of wrong parameters, or give me hints as to what type it wants. I generally don't need to explicitly test the type, as if it is of the wrong type (at least a wrong type of duck) then it will throw an error when I do something it doesn't know how to do it. Thus, unless the exact type of exception is important (and it usually isn't) there is no need to test and throw a specific type of error. -- Richard Damon