'id' is a bad variable name in Python
Question:
Why is it bad to name a variable id
in Python?
Answers:
Because it’s the name of a builtin function.
It’s bad to name any variable after a built in function. One of the reasons is because it can be confusing to a reader that doesn’t know the name is overridden.
id
is a built-in function in Python. Assigning a value to id
will override the function. It is best to either add a prefix as in some_id
or use it in a different capitalization as in ID
.
The built in function takes a single argument and returns an integer for the memory address of the object that you passed (in CPython).
>>> id(1)
9787760
>>> x = 1
>>> id(x)
9787760
id()
is a fundamental built-in:
Help on built-in function id
in module
__builtin__
:
id(...)
id(object) -> integer
Return the identity of an object. This is guaranteed to be unique among
simultaneously existing objects. (Hint: it's the object's memory
address.)
In general, using variable names that eclipse a keyword or built-in function in any language is a bad idea, even if it is allowed.
I might say something unpopular here: id()
is a rather specialized built-in function that is rarely used in business logic. Therefore I don’t see a problem in using it as a variable name in a tight and well-written function, where it’s clear that id doesn’t mean the built-in function.
Because python is a dynamic language, it’s not usually a good idea to give a variable and a function the same name. id() is a function in python, so it’s recommend not to use a variable named id. Bearing that in mind, that applies to all functions that you might use… a variable shouldn’t have the same name as a function.
id
is a built-in function that gives the identity of an object (which is also its memory address in CPython). If you name one of your functions id
, you will have to say builtins.id
to get the original (or __builtins__.id
in CPython). Renaming id
globally is confusing in anything but a small script.
However, reusing built-in names as variables isn’t all that bad as long as the use is local. Python has a lot of built-in functions that (1) have common names and (2) you will not use much anyway. Using these as local variables or as members of an object is OK because it’s obvious from context what you’re doing:
Example:
def numbered(filename):
with open(filename) as file:
for i, input in enumerate(file):
print("%s:t%s" % (i, input), end='')
Some built-ins with tempting names:
id
list
, dict
map
all
, any
complex
, int
dir
input
slice
sum
min
, max
object
file
(removed in Python 3.0)
buffer
(removed in Python 3.0)
In PEP 8 – Style Guide for Python Code, the following guidance appears in the section Descriptive: Naming Styles :
-
single_trailing_underscore_
: used by convention to avoid conflicts
with Python keyword, e.g.
Tkinter.Toplevel(master, class_='ClassName')
So, to answer the question, an example that applies this guideline is:
id_ = 42
Including the trailing underscore in the variable name makes the intent clear (to those familiar with the guidance in PEP 8).
Others have mentioned that it’s confusing, but I want to expand on why. Here’s an example, based on a true story. Basically, I wrote a class that takes an id
parameter but then tried to use the builtin id
later.
class Employee:
def __init__(self, name, id):
"""Create employee, with their name and badge id."""
self.name = name
self.id = id
# ... lots more code, making you forget about the parameter names
print('Created', type(self).__name__, repr(name), 'at', hex(id(self)))
tay = Employee('Taylor Swift', 1985)
Expected output:
Created Employee 'Taylor Swift' at 0x7efde30ae910
Actual output:
Traceback (most recent call last):
File "company.py", line 9, in <module>
tay = Employee('Taylor Swift', 1985)
File "company.py", line 7, in __init__
print('Created', type(self).__name__, repr(name), 'at', hex(id(self)))
TypeError: 'int' object is not callable
Huh? Where am I trying to call an int? Those are all builtins…
If I had named it badge_id
or id_
, I wouldn’t have had this problem.
Why is it bad to name a variable id
in Python?
Because it’s the name of a builtin function.
It’s bad to name any variable after a built in function. One of the reasons is because it can be confusing to a reader that doesn’t know the name is overridden.
id
is a built-in function in Python. Assigning a value to id
will override the function. It is best to either add a prefix as in some_id
or use it in a different capitalization as in ID
.
The built in function takes a single argument and returns an integer for the memory address of the object that you passed (in CPython).
>>> id(1)
9787760
>>> x = 1
>>> id(x)
9787760
id()
is a fundamental built-in:
Help on built-in function
id
in module
__builtin__
:id(...) id(object) -> integer Return the identity of an object. This is guaranteed to be unique among simultaneously existing objects. (Hint: it's the object's memory address.)
In general, using variable names that eclipse a keyword or built-in function in any language is a bad idea, even if it is allowed.
I might say something unpopular here: id()
is a rather specialized built-in function that is rarely used in business logic. Therefore I don’t see a problem in using it as a variable name in a tight and well-written function, where it’s clear that id doesn’t mean the built-in function.
Because python is a dynamic language, it’s not usually a good idea to give a variable and a function the same name. id() is a function in python, so it’s recommend not to use a variable named id. Bearing that in mind, that applies to all functions that you might use… a variable shouldn’t have the same name as a function.
id
is a built-in function that gives the identity of an object (which is also its memory address in CPython). If you name one of your functions id
, you will have to say builtins.id
to get the original (or __builtins__.id
in CPython). Renaming id
globally is confusing in anything but a small script.
However, reusing built-in names as variables isn’t all that bad as long as the use is local. Python has a lot of built-in functions that (1) have common names and (2) you will not use much anyway. Using these as local variables or as members of an object is OK because it’s obvious from context what you’re doing:
Example:
def numbered(filename):
with open(filename) as file:
for i, input in enumerate(file):
print("%s:t%s" % (i, input), end='')
Some built-ins with tempting names:
id
list
,dict
map
all
,any
complex
,int
dir
input
slice
sum
min
,max
object
file
(removed in Python 3.0)buffer
(removed in Python 3.0)
In PEP 8 – Style Guide for Python Code, the following guidance appears in the section Descriptive: Naming Styles :
single_trailing_underscore_
: used by convention to avoid conflicts
with Python keyword, e.g.
Tkinter.Toplevel(master, class_='ClassName')
So, to answer the question, an example that applies this guideline is:
id_ = 42
Including the trailing underscore in the variable name makes the intent clear (to those familiar with the guidance in PEP 8).
Others have mentioned that it’s confusing, but I want to expand on why. Here’s an example, based on a true story. Basically, I wrote a class that takes an id
parameter but then tried to use the builtin id
later.
class Employee:
def __init__(self, name, id):
"""Create employee, with their name and badge id."""
self.name = name
self.id = id
# ... lots more code, making you forget about the parameter names
print('Created', type(self).__name__, repr(name), 'at', hex(id(self)))
tay = Employee('Taylor Swift', 1985)
Expected output:
Created Employee 'Taylor Swift' at 0x7efde30ae910
Actual output:
Traceback (most recent call last):
File "company.py", line 9, in <module>
tay = Employee('Taylor Swift', 1985)
File "company.py", line 7, in __init__
print('Created', type(self).__name__, repr(name), 'at', hex(id(self)))
TypeError: 'int' object is not callable
Huh? Where am I trying to call an int? Those are all builtins…
If I had named it badge_id
or id_
, I wouldn’t have had this problem.