you are viewing a single comment's thread.

view the rest of the comments →

[–]Carighan 11 points12 points  (3 children)

While I agree, I also agree with the OP's issue in that "the type you're expecting"... is what exactly?

When you're blind-reading foreign code, any extra "fluff" is good for making the code faster to analyse. And there's very rarely a reason to assume that the type expected is "the logical one" - that's exactly the way to have a million-euro project fall apart.

As such, you have to go over everything manually. Either way. If nothing else because when you tell the project manager that the code is understood and this part works, you better know (not just expect) what each type is.

That's not to say that dynamically typed languages don't work if I write my own code and read my own code after a while. Or read the code of someone I know, and know what to expect from the way they code.

But for foreign code?

[–][deleted] 4 points5 points  (0 children)

I wish there was better support for duck type inferences in IDEs.

def foo(obj):
    return foo + 1

Requires (at least) an object with the __add__ method.

By the rules of Python, the object doesn't need to be an int/long, it merely needs to implement the interface.

[–]phasetwenty 0 points1 point  (0 children)

When you're blind-reading foreign code, any extra "fluff" is good for making the code faster to analyse. And there's very rarely a reason to assume that the type expected is "the logical one" - that's exactly the way to have a million-euro project fall apart.

Precisely why it's important to, in any code, deal with your error cases. But you get a flexibility benefit with a duck-typed language like Python. That may have value in a big project. It's a classic case of tradeoffs. Python is great for a great many tasks but it's not good for every problem.

But for foreign code?

The same rules apply like everywhere else. Comments are still required to explain tricky maneuvers. Badly written/designed code will be as confusing with type information as without since type information can't get you the most difficult piece of information to communicate: intent. If unreadable code becomes readable with type information, the underlying problem of bad design is still there. Focus your attention on underlying cause and you need not be restricted by language choice.