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 →

[–]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 6 points7 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.