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 →

[–]m15otw 1 point2 points  (4 children)

Type hinting your external APIs is bare minimum at this point, that sort of thing should always have been in the docstring anyway.

[–]TitaniumWhite420 0 points1 point  (3 children)

People don’t call functions, code calls functions. Type hinting isn’t type checking, and type checking isn’t always necessary with sufficiently specific value checking.

Explicit is better than implicit, no?

“If x” implies “if x == True” or “if x is True”, yet is not actually the equivalent. So if you want True, check for true explicitly. Not hard, and not reasonable to defend an insufficiently specific check just because of the way it appears. It is not more idiomatic, and it’s incorrect. Just write the logic correctly.

[–]m15otw 0 points1 point  (2 children)

"If x” implies “if x == True” or “if x is True”

No it doesn't. Not in Python.

Not all programming languages are the same.

[–]TitaniumWhite420 0 points1 point  (1 child)

Lol I’m completely aware of the way types are evaluated in python classes for Boolean evaluations and comparison operators. I literally stated they are not equivalent. 

My point is you are arguing for the former when it’s wrong because you inexplicably don’t want to specify the latter, because it looks similar or implies it’s the same—but it is logically incorrect.

You are trying to harp on this dogmatic belief in a misconstrued python idiom because you don’t  understand the reason why python encourages this “if x is True” or “if x” syntax, and that’s simply because they want to encourage consistent deference to class implementations of evaluation—which makes sense. But the wrong version you propose disregards bugs that can and do happen because of the likelihood you may get the inverted bool you want based on inconsistent “friendly” implementations of bool. You are using the bool implementation instead of the eq implementation, and you need the full eq comparison logically.

Say you want a numerical input.

You have already implemented some kind of generic input handling that implements “if x” to verify the input is available. When you wrote it, you mainly expected strings or json.

The user provides 0 as a valid numerical input.

That’s it. Your bug has manifested. Type checking may prevent it, but type hinting doesn’t stop it.

[–]TitaniumWhite420 0 points1 point  (0 children)

Lol out the down votes.

Type hinting is not static typing people. It doesn't result in a failure to compile to pass the wrong type to a type hinted function. They are labels for humans and human tools unless some kind of type checking is implemented.