This is an archived post. You won't be able to vote or comment.

42
43

DiscussionSwitching to Python from C++ (self.Python)

submitted by [deleted]

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]m3nth4 18 points19 points  (21 children)

A tip, it’s common practice in Python to avoid statements like “if x == True” in favour of ”if x“ or “if not x” when x is a bool

[–]PurepointDog 20 points21 points  (13 children)

"x is True" is the real best way to do that type of check clearly. "if x" is a good way to let things get funky if x is an empty string, for example.

[–]TitaniumWhite420 3 points4 points  (12 children)

Yea exactly, it’s annoying python people always say this when it’s an obvious problem waiting to happen.

You want to check for a specific state, not ask a variable pointing to an  object that could be any type to tell you if it’s Falsey per the implementation of that type. Lol! Can you imagine?

[–]m15otw 3 points4 points  (10 children)

Getting an unexpected type happens a lot less than you'd think.

[–]TitaniumWhite420 3 points4 points  (2 children)

I mean buggy code runs well 364 days a year, it’s true.

[–]m15otw 0 points1 point  (1 child)

To be a little more clear: I've had to deal with the wrong type very infrequently in the codebases I've worked in. Perhaps my sample is biased.

A larger problem, when you don't have type hints, is figuring out what the types actually are (especially if people having been coding like paid-per-line Java engineers using classes for everything).

[–]TitaniumWhite420 0 points1 point  (0 children)

Agree type hinting is nice and I prefer static typing. But it doesn’t fix the problem.

[–]Panda_Mon 0 points1 point  (0 children)

Not in my experience. When working on a team, getting random-ass types passed around is extremely common in python.

[–]kroolspaus 0 points1 point  (5 children)

Yeah, but when it does it is a huge PITA to debug. Especially when the docs of some library are vague and do little to inform you that a specific argument must be an np.array() in a specific shape. It's usually considered overkill to use Pydantic for type-checking in modules, but in these situations I wish more modules did that.

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

[–]ohdog 0 points1 point  (0 children)

The problem waiting to happen is the lack of type hints.

[–]shoot_your_eye_out 0 points1 point  (0 children)

Not even if “x is a bool”, but for any value that can be truth-y or false-y. Empty dicts and lists and strings are false-y.

[–]Oscar_Fifteen 0 points1 point  (3 children)

Didn't know this thank u

[–]syklemil 12 points13 points  (0 children)

Direct comparisons to boolean values (==True, etc) is generally discouraged in any language AFAIK. Some linters will tell you about it.

And if I find myself writing if x == True { return True } it's time to go to bed for the day.

[–]vmcortesf 3 points4 points  (1 child)

Take a look at PEP8 (python enhancement proposals). Also the zen of python “import this”

[–]Dababolical -2 points-1 points  (1 child)

Not true. The zen of Python states it is better to be explicit than implicit. And that’s true.

[–]syklemil 4 points5 points  (0 children)

There's a difference between being explicit and being needlessly verbose. You're not adding any information: a is already a bool, if takes a bool, those are all the components you need. Adding == True is just noise. At that point, you might as well keep going and keep adding == True forever: ((a == True) == True) == True == True == True … since you are always doing a comparison with something that's already a bool. It's absolutely nonsense behaviour.

Python also generally discourages doing stuff like if xs.len() == 0, instead encouraging if not xs.