Don't highlight builtins used as kwarg.#17
Conversation
Don't highlight builtins immediately followed by an equal sign, as they are likely being used as keyword argument to a function, e.g. `func(min=foo, max=bar)`. (Similarly to the case of attributes named using a builtin, it is unlikely that client code has the choice there anyways.)
|
I think this is counterproductive, as the kwarg is overriding a builtin function and therefore should be highlighted differently. |
|
From the point of vue of client code (calling the function), there is no overriding happening (and, as mentioned above, client code doesn't really have a choice). Given that this is the most common case (you only define a function once, but it is (usually...) called multiple times), I think it should have priority. At the function definition site, I agree that a different highlighting may be better. If one really wants to implement this, one could try to see whether you're in a function signature e.g. by checking if the next closing parenthesis is followed by a colon (modulo a return value annotation). However, in practice, the override is only a potential issue if the argument is used at least once (otherwise, it is harmless). In that case, the overridden builtin will at least appear highlighted as a builtin once in the body of the function. |
|
Trying to parse for definition vs call is going to be very complex and not worth it. This is obviously subjective and therefore should be user configurable and disabled by default. |
|
Sounds OK to me. However it should probably be a disabling option, e.g. |
|
No, the option should be called |
|
I'll implement it. |
|
Thanks! |
Don't highlight builtins immediately followed by an equal sign, as they
are likely being used as keyword argument to a function, e.g.
func(min=foo, max=bar). (Similarly to the case of attributes namedusing a builtin, it is unlikely that client code has the choice there
anyways.)