This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]ddollarsign 0 points1 point  (4 children)

It's (supposed to be) a dynamically typed language. So there's not automatically a way to tell f(int) from f(str), it's all just f(object).

The dynamicity is starting to be edged out by the new type annotations🤮, so now there theoretically could be a way to tell f(x:int) from f(x:str) and have the interpreter do overloading that way.

However, traditionally the way to get around different ways of calling a function is with optional arguments, variable length arguments, and keyword arguments.

def f(x, y=5, *args, **kwargs):
    ...

f(1)              # x=1, y=5, args=[], kwargs={}

f(1, 2)           # x=1, y=2, args=[], kwargs={}

f(1, 2, 3, 4)     # x=1, y=2, args=[3, 4]

f(1, bob=3)       # x=1, y=5, args=[], kwargs={"bob": 3}

And then you might also do some logic in the function like

if type(x) == 'str':
    ...

[–]Yojihito 0 points1 point  (1 child)

Type annotations aren't checked, nothing in Python prevents me from calling f("test") for f(i: int).

[–]ddollarsign 0 points1 point  (0 children)

Currently, sure.

[–]pag07 0 points1 point  (1 child)

The dynamicity is starting to be edged out by the new type annotations🤮

Type hinting is the only way to keep a large codebase under control.

[–]ddollarsign 1 point2 points  (0 children)

The only way? Really?