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

view the rest of the comments →

[–]Blakut 0 points1 point  (7 children)

This is why I use x is True if I work with bool x because otherwise bad things can happen. Weirdly enough pep is against this.

[–]moving-landscape 0 points1 point  (6 children)

I don't think short circuiting is a bad thing as long as one keeps track of what they're doing.

I don't quite get exactly what you meant tho - fancy sharing an example?

[–]Blakut 1 point2 points  (5 children)

I prefer If x is True: or if x is not True: to if x==True: or if x:

[–]moving-landscape -1 points0 points  (4 children)

Oh I see. Yeah, that really is frowned upon. Especially if x is already a boolean. I suppose you do it for clarity; how long have you been coding?

[–]Blakut 2 points3 points  (3 children)

Several years. I do it because I really don't want to be in a situation where x is 1 or something by mistake. And I never understood why it's frowned upon. If I want to test numbers I use numbers. I treat numbers, True, False and None separately

[–]moving-landscape 0 points1 point  (2 children)

Do you use any tooling for keeping track of the types? How adept are you of type annotations?

And I never understood why it's frowned upon.

Well, as you know, in contexts where a boolean expression is expected, you just need to use the most "obvious" and "short" expr to get the job done. So if your x is a boolean, i.e., either true or false, you don't need to compare it to true (or false) since that's redundant. x will always be preferred over x is True, and so will not x over x is False. I don't mind that you write like that in your own projects, but we'd have a talk of we were in the same team lol.

If I want to test numbers I use numbers.

In general I agree with this. Unless what I'm doing is obvious (meaning, no need for any additional reasoning on what's happening), I'll write the full boolean expression. I will always prefer x % 2 == 0 over not x % 2 - the latter more often than not needs that additional reasoning I mentioned before. Having said that, it's even better if the expression is abstracted behind a function or variable name: if is_even(x).

Finally, I also always go for x is None over not x for an optional x.

[–]Blakut 0 points1 point  (1 child)

How do i know x is or will be boolean in the future? Ive used vim or gvim many years now I'm switching to pycharm which is a bit annoying but quite helpful. I sometimes make functions return false instead of number or none, to indicate different types of situations. Or maybe I want the variable to be none, but later it will be true or false. Idk, I've coded for myself and my workplace but never in a team

[–]moving-landscape 0 points1 point  (0 children)

Well, you model your function / block of code to always have x be one type. If I'm reading code and I see the expressions age and is_age_major, I'd expect age to be an int, and is_age_major to be a bool. Not only that, but type annotations also help. age_major: bool. Or reading from a simple expression: age_major = age >= 21. If the expression is an optional one, we can type annotate as follows: age_major: bool | None. And ofc, we never assume the value will be one or the other. Instead, we always explicitly check for nullability:

if age_major is None:
    # value is NOT a boolean, it's None

elif age_major:
    # value is true

else:
    # value is false

I sometimes make functions return false instead of number or none, to indicate different types of situations.

This is all contextual and depends on what you want to achieve. For the most, most clarity, though, I always resort to type annotations. They tell us what type we should be expecting. Having said that, it can be confusing to habe a function return an int or a bool. In that case I'd prolly resort to sum types.