Thank you all. It was just that when I started with Python, everything worked right like I expected, and I found the ways to do anything I've needed all the way until today, so when I came across with this, it appeared to me a clear bug in the language/interpreter. Casting to bool is indeed a good solution and practice, and I do now agree that there's no point in changing the language - like Antoine said, we're talking control flow operators here, not exactly boolean. (This might be a good addition to the documentation.)Thank you Ned for the warm welcome and everyone for your input. I hope to be able to contribute in the future. :)Best Regards,IlkkaOn Thu, Jan 17, 2013 at 6:07 PM, Mathias Panzenböck <email@example.com> wrote:
This change would break a lot of existing code and would make Python awkwardly stand out from all
bar = bar or 
obj = obj and obj.property
The proposed change would needlessly complicate these things and break existing code. Forcing a
bool type really doesn't require that much code (bool(expr)) and is good practise anyway.
On 01/17/2013 01:44 PM, Ilkka Pelkonen wrote:
I ran into an issue in expression evaluation with Python for Windows 2.7.3. Consider the following code:
expected_result = (expected_string != 'TRUE') # Boolean
element = find_element() # Can return None or an instance of Element
flag = (element and element.is_visible())
if flag == expected_result:
# Otherwise perform some failure related stuff.
This code does not work. What happens on the 'flag' assignment row, is that if 'element' is None, the expression returns None, not False. This makes the if comparison to fail if expected_result is False, since boolean False is not None.
To me as a primarily C++ programmer it seems there could be two different changes here, either change the behavior of the 'and' expression, forcing it to return Boolean even if the latter part is not evaluated, and/or make the comparison "False == None" return True. Although potentially complex, I'd
myself go for the first approach. It seems to me more logical that False != None than an 'and' expression returning non-boolean. Also the latter change might require people change their code, while the former should not require any modifications.
This behavior probably results in lots of errors when people like me, used to more traditional languages, take on Python in a serious manner. I like the concept 'pythonic', and am trying to apply it to practice like above.
Hoping to hear your thoughts,
Python-ideas mailing list