53

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,
):
Anton Menshov
  • 2,266
  • 14
  • 34
  • 55
Niklas Rosencrantz
  • 25,640
  • 75
  • 229
  • 424

6 Answers6

70

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.

Brian Gesiak
  • 6,648
  • 4
  • 35
  • 50
  • 8
    However, inside the function scope I don't see a big issue with it. Same for `id` which is even more common. – ThiefMaster May 12 '12 at 23:13
  • 5
    I avoid using naming variables `id` for just this reason. Isn't this a bad idea, since other developers could try to use the builtin and experience strange behavior? If you could provide a link to a framework/library that does this I'd be willing to reconsider. – Brian Gesiak May 12 '12 at 23:16
  • 4
    IMHO it really depends on the context and the function. – ThiefMaster May 12 '12 at 23:19
  • 5
    I was just on the receiving end of some code that defined ```list``` as a variable. It was a bit of a sprawling function so it wasn't immediately obvious that the ```list()``` builtin was being masked when I tried to use it. – liquidki Mar 08 '17 at 02:55
16

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.

Wooble
  • 87,717
  • 12
  • 108
  • 131
8

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
arshbot
  • 12,535
  • 14
  • 48
  • 71
3

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.

sorin
  • 161,544
  • 178
  • 535
  • 806
0

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.

Kermit
  • 4,922
  • 4
  • 42
  • 74
  • Even though it is true that we have a [built-in function](http://docs.python.org/library/functions.html#type), I cannot find `type` among the reserved words in [here](https://docs.python.org/3/reference/lexical_analysis.html#keywords). Am I missing something? Anyway I will follow your advice and use another word. – ingroxd Sep 28 '21 at 18:40
0

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.