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,
):

Camargo

Answer 1

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.

Haem

However, inside the function scope I don't see a big issue with it. Same for id which is even more common. – Tatty

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. – Haem

IMHO it really depends on the context and the function. – Tatty

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. – Hartwig

What about upper case Type? – Epistrophe

Answer 2

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.

Hereinbefore

Incidentally, import keyword; print keyword.kwlist will accomplish the same thing. – Vanya

Answer 3

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

Azaleah

If you use typing hints, the first is not okay. Consider this: class SomeClass: type: type | None = None – Bowlder

Answer 4

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.

Xylograph

Answer 5

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.

Thermocouple

Even though it is true that we have a built-in function, I cannot find type among the reserved words in here. Am I missing something? Anyway I will follow your advice and use another word. – Yawmeter

Answer 6

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.

Postmortem