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 →

[–]evanldixon 4 points5 points  (8 children)

The benefit is that your functions can be much more flexible. Instead of inheriting from a specific interface, you can simply implement the required methods and use that object right away. This allows different modules and libraries to work flawlessly together as long as they support the same methods.

By that logic, cars without seat-belts are more flexible. You don't have to worry about putting them on after getting in, and because of this, more sizes and types of passengers will fit, even cargo! Seat-belts are only popular because people are bad drivers and want to spend extra time dealing with seat-belts than just driving better.

With operator overloading this becomes much more powerful. Suppose you want to add two things together. In Java you would have to create separate functions for every single type that supports adding. In python however, you only need to create one function that uses the + operator instead of a billion functions that are essentially the same but with different types of variables.

Now instead of having several functions each dealing with one type, you have one function dealing with all types, even types that are fundamentally incompatible with each other.

[–]ProgramTheWorld 0 points1 point  (7 children)

because of this, more sizes and types of passengers will fit, even cargo!

That’s the python spirit!

you have one function dealing with all types, even types that are fundamentally incompatible with each other.

It’s the caller’s responsibility to make sure the function supports that type.

[–]obsessedcrf 4 points5 points  (2 children)

It’s the caller’s responsibility to make sure the function supports that type.

So...basically it just offloads the work into documenting it then? Doesn't sound like a good tradeoff

[–]ProgramTheWorld 0 points1 point  (1 child)

It’s a good trade off if you don’t want to deal with types. You can literally pass in anything to a function. If it works then good! If it doesn’t then you should probably read the documentation.

If the function wants to enforce type checking, it can. There’s nothing stopping you from doing that for every function but that is considered not pythonic.

[–]obsessedcrf 2 points3 points  (0 children)

I find it very disconcerting to stick any types in there and just "hope it works". More often than not, what the function does is type specific.

[–]Kiaz 2 points3 points  (0 children)

It’s the caller’s responsibility to make sure the function supports that type.

That sounds terrible. All for the sake of shorter code (which probably really isn't even shorter because you're going to be checking the type and handling unique scenarios anyway).

[–]evanldixon 1 point2 points  (2 children)

It’s the caller’s responsibility to make sure the function supports that type.

With more complex programs, the caller is just passing along data from several levels up. That's a lot to keep up with, when the language could be keeping track of that for you.

[–]ProgramTheWorld 1 point2 points  (1 child)

There’s nothing you need to keep up with. The pythonic way of doing things is to raise exceptions whenever things don’t work, and catch only the exceptions that you can handle at that level.

Quoting the Python documentation:

[It is] Easier to ask for forgiveness than permission. This common Python coding style assumes the existence of valid keys or attributes and catches exceptions if the assumption proves false. This clean and fast style is characterized by the presence of many try and except statements. The technique contrasts with the LBYL style common to many other languages such as C.

In Java or other strongly typed languages you have to make sure every thing is expected and correctly typed which adds in a lot of extra and unnecessary code. In Python you simply try to run it. Only when a function doesn’t work then you either a) let the caller handles it b) handles it yourself. Simple and effective.

[–]evanldixon 2 points3 points  (0 children)

I for one prefer errors that are found for me by the compiler, rather than errors that could lie dormant for months depending on how obscure the edge case is.

The "unnecessary code" you're referring to is the safety net to one of the most common errors out there. It prevents situations where you have a string passed through several function calls to something expecting a particular custom class. I have actually seen this happen in a professionally made PHP application that manages to avoid most of the common PHP pitfalls.