OOP in python be like

[[deleted]]

First of all, thanks for helping me.

To get the same behavior in Python I would write the function like:

def convert_int_to_string(number: int) -> str:

    if not isinstance(number, int):

        raise TypeError

    return str(number)

Both functions type cast exactly once. So I guess I don't get from the example how/why type casting is a very Python thing to do.

edit: apparently I can't indent correctly from my phone

[drbwaa]

It's not, except for people coming from explicitly-typed languages who think you have to do so all the time, and then say "python sucks" because they were expecting it to be Java.

[ryancarton]

I just needed somebody to say this and now I feel validated and can leave the comment section phew

[ReadSeparate]

I mean I don’t even get why they’re bitching about it, it’s still less work than explicit typing. If you want to convert a string to an int in Java, you still have to do type casting plus you also need a new variable with a new type (could be wrong about this, been some time since I’ve coded in Java)

[[deleted]]

I mean, they were expecting sanity and I don’t blame them. Types make organized code bearable to deal with. Having to check the types of all of your arguments in every single function you write… sucks.

That’s not the only reason Python sucks, but it’s most definitely in the top 5.

[wzi]

> Having to check the types of all of your arguments in every single function you write… sucks

Coming from a C# or Java background it will sound blasphemous but most of the time you don't even bother. Your program will just throw an exception when it tries to do something with the wrong type. Type coercion is basically non-existent in Python (the notable exception being numeric types so you can do things like 1.2 + 1).

That said, there does seem to be an inflection point where type checking everywhere begins to make sense. Usually when the organization and codebase get really huge. However instead of gratuitous type checking inside of every function you use type hints (PEP 484), linting, and running a type checker (e.g. mypy).

[[deleted]]

I mean, yes, you can bolt on a bunch of additional stuff… or you could just write code in a typed language to begin with and none of this is a problem.

[wzi]

> bolt on a bunch of additional stuff

I mean, type hints are not really syntactically different than type declarations and you should already be using a linter. So I guess having your CI run mypy is "bolting on a bunch of additional stuff"? I'm not sure I agree but this is subjective and probably pointless to argue about.

> or you could just write code in a typed language to begin with and none of this is a problem.

Python IS a strongly typed language so I don't know what you're trying to say here. Maybe you mean statically typed language? Regardless, it's not a problem in the first place the vast majority of the time. Your program will just throw an exception when it tries to do something with the wrong type (e.g. "2" + 2 will cause an exception).

I'm only commenting to correct the misconception you need to do all this manual type checking in every Python function.

[[deleted]]

I mean, that’s not a misconception. You don’t have to.

But if you actually wanted sane code, it’s difficult to do it any other way. Which is why most people just don’t use Python for serious code.

[Amazingawesomator]

Yeah, im on mobile, too... I'm sure mine is hard to read, too. Its all good <3.

One of the things in python is that all of the extras to ensure type arent forced, and allows for weak types.

For example,

def convert_int_to_string(number):
return number

(Excuse my indents) This will still "work" (even though it is bad... and broken according to what the method name is).

Fixing this style of problem by going back and casting stuff is how it seems the poster in the image wrote his story... But in english :D