Is it safe to use the python word "type" in my code?
Question:
Can I use the word type in my own code or is it reserved? My function header:
def get(
self,
region='Delhi',
city='Delhi',
category='Apartments',
type='For sale',
limit=60,
PAGESIZE=5,
year=2012,
month=1,
day=1,
next_page=None,
threetapspage=0,
):
Answers:
Neither. It’s not a reserved word (a list of which can be found at http://docs.python.org/reference/lexical_analysis.html#keywords ), but it’s generally a bad idea to shadow any builtin.
Using type as a keyword argument to a function will mask the built-in function “type” within the scope of the function. So while doing so does not raise a SyntaxError, it is not considered good practice, and I would avoid doing so.
type should absolutely be consider a reserved word. While it can be tempting to use this word for database fields, consider that the fact that type() is one of the most important debugging/ testing functions because it tells you the class of an object.
$ python
>>> x = 5
>>> s = "rockets"
>>> y = [1,2,3]
>>> print(type(x))
class 'int'
>>> print(type(s))
class 'str'
>>> print(type(y))
class 'list'
An atlas would be classified a type of book, but consider using the word “category” instead.
While others have pointed out that it’s bad form to shadow python built-ins, this is only the case when either name a function or function parameter as type, however –
It should be noted that the python built-in type is not shadowed in any way if you were to name a class attribute as type.
Even when referencing your class attribute, it would always be prefixed by the class instance self or a custom instance variable – and the python built-in would not be hindered.
For example:
Okay:
>>> class SomeClass():
... type = 'foobar'
...
... def someFunction(self):
... return self.type
Not Okay:
>>> def type(): # Overrides python built-in in global scope
... pass
...
>>> def foobar(type):
... return type # Overrides python built-in within func
That is more than a decade old question and to be on the safe side, I would recommend using kind instead of type as argument.
For a long time I was considering building a rename recommendation for all reserved or builins, but seeing your question made me finally do it.
Please check python-keyword-aliases.md and feel free to propose new entries to that list.
A definitive con with shadowing builtin variables like type and id: if you happen to copy/paste your code that overshadows id for example, and then you replace all the instances of your variable with something else, but forget to rename one instance so you still have dangling id used, the code will still be syntactically valid and linters may very well not even find the error, but you’ll get really really weird results when you run the code, because id won’t be a string or number as you expected. It’ll be the builtin function id!
This tripped me up badly a few times.
Can I use the word type in my own code or is it reserved? My function header:
def get(
self,
region='Delhi',
city='Delhi',
category='Apartments',
type='For sale',
limit=60,
PAGESIZE=5,
year=2012,
month=1,
day=1,
next_page=None,
threetapspage=0,
):
Neither. It’s not a reserved word (a list of which can be found at http://docs.python.org/reference/lexical_analysis.html#keywords ), but it’s generally a bad idea to shadow any builtin.
Using type as a keyword argument to a function will mask the built-in function “type” within the scope of the function. So while doing so does not raise a SyntaxError, it is not considered good practice, and I would avoid doing so.
type should absolutely be consider a reserved word. While it can be tempting to use this word for database fields, consider that the fact that type() is one of the most important debugging/ testing functions because it tells you the class of an object.
$ python
>>> x = 5
>>> s = "rockets"
>>> y = [1,2,3]
>>> print(type(x))
class 'int'
>>> print(type(s))
class 'str'
>>> print(type(y))
class 'list'
An atlas would be classified a type of book, but consider using the word “category” instead.
While others have pointed out that it’s bad form to shadow python built-ins, this is only the case when either name a function or function parameter as type, however –
It should be noted that the python built-in type is not shadowed in any way if you were to name a class attribute as type.
Even when referencing your class attribute, it would always be prefixed by the class instance self or a custom instance variable – and the python built-in would not be hindered.
For example:
Okay:
>>> class SomeClass():
... type = 'foobar'
...
... def someFunction(self):
... return self.type
Not Okay:
>>> def type(): # Overrides python built-in in global scope
... pass
...
>>> def foobar(type):
... return type # Overrides python built-in within func
That is more than a decade old question and to be on the safe side, I would recommend using kind instead of type as argument.
For a long time I was considering building a rename recommendation for all reserved or builins, but seeing your question made me finally do it.
Please check python-keyword-aliases.md and feel free to propose new entries to that list.
A definitive con with shadowing builtin variables like type and id: if you happen to copy/paste your code that overshadows id for example, and then you replace all the instances of your variable with something else, but forget to rename one instance so you still have dangling id used, the code will still be syntactically valid and linters may very well not even find the error, but you’ll get really really weird results when you run the code, because id won’t be a string or number as you expected. It’ll be the builtin function id!
This tripped me up badly a few times.