Noissue - Improved accuracy of evaluated expressions for A103 and A207

flake8-eyeo/tests/A103.py

 def compare_int_like_yoda(x):
     #      * A103
     return 1 == x
 
 
 def compare_string_like_yoda(x):
     #      * A103
     return 'foo' == x
 
 
 def compare_none_like_yoda(x):
     #      * A103
     return None is x
 
 
 def compare_tuple_like_yoda(x):
     #       * A103
     return (1, 'foo') == x
 
 
 def compare_literals():
     return (1, 'foo') == (2, 'bar')
 
 
 def compare_variables(a, b, c, d):
     return (a, b) == (c, d) or a == b
+
+
+def compare_builtin(x):
+    return dir == x

[Sebastian Noack, 2017/10/05 22:07:11]

This was causing an A103 (yoda expression), since we determine whether something
is a constant expression with eval(). So that if it can successfully be executed
without accessing any global or local variables, it is considered a constant
expression, and constant expressions read weird on the left hand side of a
comparison. However, eval('dir', {}) doesn't fail because "dir" is a builtin.

[Vasily Kuznetsov, 2017/10/06 10:46:21]

Isn't this kind of a genuine yoda expression though, since `dir` is more or less
like a constant (and we even show another error if people try to redefine it)?
Same for the other builtins.

[Sebastian Noack, 2017/10/06 18:11:09]

Another way to look at it is that builtin functions are rather like default
globals than an inherit part of the programming language. Hence in the (rather
theoretical) case of `dir == orig_dir` this doesn't quite sound like Yoda speak,
while `0 == foo` or `False is foo` certainly does. Another (much more common)
case is when builtin names (like "dir") are shadowed by local variables. It took
me quite a while to figure out where the bogus A111 came from in this line:
https://hg.adblockplus.org/buildtools/file/d4ca9bfb82b5/localeTools.py#l412