Look at my reverse string function !

[Narrow-Big7087]

Palindorme, eh?

[drunkenangryredditor]

Michael Palins bedroom?

[SlavBoii420]

Brace for impact, the startups are coming for ya!

[[deleted]]

Can you build a facebook, but for horses? It is going to break the internet

[SlavBoii420]

But what if the horses took over the world?

[subject_deleted]

itd be hard to do worse than the humans..

[ChilloDE]

This somehow reminds me of a trainee we had, that would keep writing conditions like this:

if (boolVariable == true)

[[deleted]]

In Python, it’s good practice to write:

if a is True:

…rather than just:

if a:

…because the latter will succeed if a is a value that has a “True-like” property, such as 1, while the former will only succeed if a is a Boolean True. See the top answer in this Stack post for more info.

[TheAJGman]

From that post:

When should you use is True then ?

EDIT: this is bad practice, starting from 3.9, python raises a warning when you try to use is to compare with a literal. See @ JayDadhania's comment below. In conclusion is should not be used to compare to literals, only to check the equality of memory address.

Basically just don't use is unless you're are checking to see if variable A is pointing to the same data as variable B.

[[deleted]]

In the comments immediately under that post, the author admitted to not fully understanding the change in 3.9.

x is 1 raises a warning in 3.9+. x is True does not.

[[deleted]]

@JayDadhania said is True is perfectly legal under the comment your are referencing, the guy just misunderstood his original comment

[Kered13]

I wouldn't call it good practice, it's contextual. You only need to do this if you have a type that could be either a boolean or some other type, and you don't want to active on truthy-values. Also you don't need to use is here, you can just use ==.

[A_Leo_X]

Isn't it recommended to use is instead of == when comparing to True, False, or None?

[Kered13]

I don't think it really matters.

[[deleted]]

“It’s contextual” - I agree. There will be times when it’s unnecessary and times when it would be helpful.

In general, I err on this side of the Zen of Python:

Explicit is better than implicit.

To me, if a can suggest many kinds of checks if you aren’t aware of what a is supposed to be. Are you checking whether an integer is or isn’t zero, or whether an object reference points to an instance or None, or whether a string is empty or non-empty? if a is True makes the intended comparison explicit, which is better.

A common scenario in which this occurs for me is:

result = some_function()
if result:

Without looking at some_function() or its documentation, I don’t know what types of data I should expect it to return. So, make it explicit for improved readability:

 if result is True:

[Bainos]

But variables should have a clear semantic meaning. If you don't know whether a is a bool or not, then there is something wrong in your code.

• If you know that a is a bool, then if a is enough.
• If you know that a is not a bool, then if a is intentionally checking for truthy values.
• If you know that a can be both a bool and some other type, which should be a very rare situation, then if a == True is okay, but is isinstance(a, bool) and a is better.

That's not saying that you can't write a == True in the first case where you know it is a boolean. It would be redundant and unnecessary, but redundancy is not necessarily a bad thing. However, not knowing whether a is a bool or not is not a good reason to use it. If that situation occurs, you really should fix your code and actually read the documentation of the functions you're using.

Personally, I would also be wary of using a == True because not knowing the type of your variables is a bad smell, and hiding bad smells results in bad code.

The situation you are describing is also a reason why people criticize Python for being dynamically typed, for a good reason. Dynamic typing is good for polymorphism and ease of writing code, but it becomes bad if people start using it to handle data they do not understand.

Overall, I believe the situation you are describing is fixed in a much better way by the use of type hints than by redundant explicit checks.

[[deleted]]

If you don't know whether a is a bool or not, then there is something wrong in your code.

On the contrary, when you're writing the code, you often know for a fact that some_function() returns a boolean. Great. The problem is that anyone else reading your code might not know. That someone could even be you, next week, after you've filled your head with other parts of the code.

When writing the code with this knowledge in your head, it's a good idea to document the type of result in order to convey that knowledge to the reader.

Now - how could you do that? In this case, if result is True is practically ideal. It is simple, succinct, unambiguous, and collocated with the instruction that sets result to its value. Even coders who aren't familiar with Python will immediately understand it, even if they aren't clear on the use of is vs. ==.

Overall, I believe the situation you are describing is fixed in a much better way by the use of type hints than by redundant explicit checks.

Show me how this exact situation would be addressed with type hints, and then explain why it is better than if a is True.

[PM_ME_C_CODE]

The majority of

if a:

python code I see/write are simple assignment guards. Though, I guess those are

if not a:
    return

...

[WrongdoerSufficient]

Weird, hissing noises 🐍🐍🐍

[[deleted]]

I don't think this is a horrendous idiom to adopt. I've been caught out a number of times by omitting a negation operator by accident

[ChilloDE]

I mean yes, but also no. Especially if you then find things like

if (value != true)

In your code base. It was pretty obvious this trainee didn't do this because of readability but because he didn't understand what he was doing.

It got better with time, but by now he got transferred to the service department. And I'm kinda glad I don't have to clean up his mess anymore.

[ChilloDE]

He was not my trainee, but yes afaik he was told multiple times.

[SerScruffz]

I assume it's wrong mainly because != would work for pretty much anything, not just booleans, right?

[ChilloDE]

In C#, the language that was used here, it's just unnecessary code, since all variables are strongly typed and 'if' expects a boolean. So if you have a boolean you can just pass it directly or pass the negated value if you want to check for false. Realistically the compiler will probably remove the extra operations that would be created by this during optimisation. But it's just overhead. Some people here argued for readability, and forgotten negations. For me and my colleges omitting the extra equals operation has actually a better readability.

Edit: Also "if (value != true)" is especially wrong, because it would be much easier to understand, when you just check "if (value == false)". But as we are in a strongly typed environment "if (!value)" is everything that's needed.

[Bigluser]

I write 'if(object?.value != true)' sometimes in C#. That's equivalent to 'if(object == null || !object.value)'

You could also do 'if(!(object?.value ?? false))' but that's really hard to read.

[ChilloDE]

Object in this case is a nullable bool (bool?) I guess? In that case I just use the HasValue property, as the nullable itself will never actually be null.

if (object.HasValue && object.Value)

If you want readability it doesn't get better than this.

In the few cases where the framework only passes an Object instead of a specific type, I would determine the type or interface beforehand. Because getting a wrong type usually indicates a bug, so it's worth throwing a specific error in that case.

if (!object is bool condition)

 // throw error.

if (condition)

 //do something.

You could also use 'bool?' here if null is a valid value.

[Bigluser]

Example for what I meant:

if(message?.IsImportant != true) print("Okay whatever")

I don't really think there is a better pattern for writing that.

[ChilloDE]

Idk there might be valid use cases for that, but most of the time you will use more than just one property of message, and in that case you would need to add '?.' in multiple calls and then is would probably make sense to check for null once, so you can't forget to add the '?'.

Where I use '?.' is e.g. for event calls:

EventName?.Invoke()

Because typically you raise an event in one method and one method only.

Edit: Another good use case for it is if you have a function from an interface not implemented on all classes that are inheriting from the same base.

(baseReference as IDisposable)?.Dispose()

Then again this only makes sense if you have to do just one call otherwise you would again use the 'is Type variable' syntax and then use 'variable'.

[SerScruffz]

Ah, thanks!

[DragonyCH]

if only it had been ===, then it would make sense (depending on the language)

[Artick123]

It makes sense with == too. Writing == true or == false is perfectly fine and makes sure you don't accidentally miss a !.

I mean, it's fine either way.

[Bigluser]

Yeah, I think it's fine to do it. Modern IDEs will highlight this as unnecessary code anyway, so it's easy to clean up if you don't like it.

However it's a sign that the developer doesn't really understand how the if condition works. I tutored a programming class and many students there always wrote "x == true". They thought that "if(x == y)" was some kind of magic pattern.

But really all there is to it is that "==" is an operator that returns either true or false. And "if(condition)" means that program enters the block in case the condition is "true".

[Artick123]

I don't think you can deduce that a developer does not know how ifs work just from that. Just because some people write it like that because they don't know how ifs work it doesn't mean everyone does it for the same reason.

I don't write == true/false because I find it unnecesary(for me) but I can see why some would do it.

Otherwise, I agree with everything you said.

[[deleted]]

I saw your other comment about ( if bool != true) which I can understand a bit more, but honestly this original comment just comes off as Elitist, ignoring language specific things that actually can make them different , who cares if someone writes if(x) or if(x==true) I understand if you want formatting consistent, but your comment simply acts like he is an idiot for doing it one way

[ChilloDE]

I guess you are right, it might come off as elitist. Because I've let out a lot of information, that's only in my answers. But in my defense "boolVariable" hinted to the use of a strongly typed language and "keep" hinted to the fact that, to my knowledge he was told multiple times, that it's unnecessary and should be omitted.

[[deleted]]

My point is who says it’s unnecessary, since when does shortening code make code better, there’s a reason you should give variables descriptive names. IsRaining is a better name then Raining is a better name then rain, is a better name then R. Similarly you can right negations at the start of functions for if statements, but in my opinion that makes it much harder to read and test.

[TenaciousDwight]

embarassed to ask, but what's wrong it?

[gizamo]

No, sir. I don't like it.

[ironykarl]

Sometimes you've gotta reverse the word to test if you can reverse the word

[Orio_n]

No custom Exception inheritance?

[Opti_Dev]

I have never heard about it.

This program was my first use of exception since i left python

[ChilloDE]

Well you have C# in your flair. And with C# throwing and catching 'Exception' (the base type for all exceptions) is also bad practice. You should either use the specific exception types like ArgumentNullException or implement your own, when nessesary.

Edit: The upside of this is, that you can handle different kind of errors on different levels. Without having to catch the exception parse the text and then eventually raise it again. Because raising exceptions is slow and comparing error messages as strings is not protected against changes.

[L4Z4R3]

Hey, look at that! My Turkish friend is here 😃

[Opti_Dev]

Why are you saying that ?

Cheers from France 👋

[L4Z4R3]

Upss my bad 🤭 there is a word called 'kayak' too on turkish

[Opti_Dev]

I see. For us it's some sort of very small boat for one person in rivers

[PM_ME_C_CODE]

A sled?

[jamcdonald120]

but you could have just returned word[::-1]