== Why is this an issue?

Shadowing a builtin makes your code more difficult to read and maintain. It may also be a source of bugs as you can reference the builtin by mistake.


It is sometimes ok to shadow a builtin to improve the readability of a public API or to support multiple versions of a library. In these cases the value is higher than the maintainability cost. Just be careful when you do it.


It is not ok to shadow builtins with variables which are local to a function or method. These variables are not public and can be easily renamed, thus reducing the confusion and making the code less error-prone.


This rule raises an issue when the name of a local variable matches the name of a builtin.


=== Noncompliant code example

[source,python]
----
def a_function():
    int = 42  # Noncompliant; int is a builtin
----


=== Compliant solution

[source,python]
----
def a_function():
    value = 42
----


== Resources

* https://docs.python.org/3.8/library/stdtypes.html[Python documentation - Built-in Types]
* https://docs.python.org/3/library/functions.html[Python documentation - Built-in Functions]


ifdef::env-github,rspecator-view[]

'''
== Implementation Specification
(visible only on this page)

=== Message

Rename this variable; it shadows a builtin.


=== Highlighting

Primary:

* The first definition of a variable shadowing a builtin in a local scope (function)

Secondary:

* Any other assignment to the variable.
* message: "Variable also assigned here."


'''
== Comments And Links
(visible only on this page)

=== relates to: S2137

=== on 30 Apr 2020, 19:12:03 Nicolas Harraudeau wrote:
This rule is similar to RSPEC-2137 but it is a code smell because shadowing builtins will not make your code crash most of the time.

endif::env-github,rspecator-view[]