Allow `len-as-condition` for explicit comparison

[timokau]

Steps to reproduce

if len([]) == 0:
  pass

pylint will lint this as len-as-condition. This seems to go back to PEP stating:

• For sequences, (strings, lists, tuples), use the fact that empty sequences are false.

Yes:

if not seq:`
if seq:

No:

if len(seq):
if not len(seq):

While I do agree that if len(seq) is not ideal, I don't think the same applies to if len(seq) == 0. I personally prefer the explicitness of the comparison and the applicability to everything that supports len. There is also the point of consistency in comarisons like:

if len(seq) == 0:
    pass
elif len(seq) == 1:
    pass

Current behavior

if len([]) and if len([]) == 0 are both linted.

Expected behavior

Only if len([]) is linted.

pylint --version output

pylint 2.2.2
astroid 2.1.0
Python 3.7.2 (default, Dec 24 2018, 03:41:55) 
[GCC 7.3.0]

[PCManticore]

This makes sense, thanks for creating an issue.

[andreasvc]

In addition, the warning is triggered even for objects for which bool() is problematic, for example numpy arrays or lxml nodes:

>>> import numpy
>>> a=numpy.zeros((3,3))
>>> if a: ...
ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()
>>> import lxml.etree
>>> b=lxml.etree.parse('1.xml').find('//node')
>>> if b: ...
FutureWarning: The behavior of this method will change in future versions. Use specific 'len(elem)' or 'elem is not None' test instead.

A solution would be to follow PEP8 by raising this warning only for (subclasses of) strings, lists, tuples. Both of the above objects implement bool() and len(), but these cannot be expected to behave the same as strings, lists, or tuples.

[PCManticore]

@andreasvc That sounds like a good suggestion, thanks.

[PaulRenvoise]

Hi @timokau @PCManticore,

I'd like to provide a fix for this issue, but I have a question:
Do we agree that the only cases where len-as-condition should be raised are only when an str, list, tuple or set's length is used in a test condition without any comparison with another constant ?

Here's a list, where 'op' is either a str, list, tuple, or set:

if len(op):
    pass

if not len(op):
    pass

if cond and len(op):  # and the other way around/when using 'or'
    pass

if cond and not len(op):  # and the other way around/when using 'or'
    pass

while len(op):
    pass

while not len(op):
    pass

while cond and len(op):  # and the other way around/when using 'or'
    pass

while cond and not len(op):  # and the other way around/when using 'or'
    pass

assert len(op)

assert not len(op)

assert len(op), msg

assert cond or len(op), msg  # as well as when using 'and'

[andreasvc]

@PaulRenvoise strictly speaking, the quoted parted of PEP8 talks only about sequences. If you're going to include set (I think you should), you should include dict as well.

[PaulRenvoise]

@andreasvc Ah, you're right, I forgot about dicts! Thanks

[timokau]

I agree in principle, but why limit the type at all? Is there any valid use case for using len as condition without explicit comparison?

[PaulRenvoise]

I created the PR #2815 to fix this issue, with the following changes:

• Remove len(xx) checks when in a comparison
• Add "without comparison" to the len-as-condition message
• Provided another suggestion in the len-as-condition description
• Marked old errors as safe, and added new error cases in len_checks.{py,txt}

[JayRizzo]

Current System

ProductName:	Mac OS X
ProductVersion:	10.14.3
BuildVersion:	18D109

$ pylint --version
pylint 2.2.2
astroid 2.1.0
Python 3.7.0 (default, Jul 23 2018, 20:22:55) 
[Clang 9.1.0 (clang-902.0.39.2)]

Hi all, I don't know if this is the most appropriate, approach on this issue, But I did want to share my findings. I did update my pylint but still got this issue.
I found that a simple work around if you want to get around this issue you can apply the .__trunc__() to the line.

As by adding the int.attribute it has satisfied the pylint complaint on this issue.
To see it in context or for more info you can see my post on SO..

Thank you all for your work & contributions, your efforts are appreciated!