Is it bad style to override the built-in function `type`?

Cameron Simpson cs at
Fri Nov 23 23:30:11 CET 2012

On 23Nov2012 10:41, Michael Herrmann <michael.herrmann at> wrote:
| I know it's a common beginner's mistake to incautiously override
| built-in functions. However, we put in a lot of research and have come to
| the conclusion that, if Python had not already defined it, `type` would
| be the best name. We are now trying to evaluate how bad the disadvantages
| you mention are in comparison to the advantage to having a name that is
| more intuitive to use in the problem domain.
| Can you somehow relate to my explanations, or are your experiences
| with overwriting built-in variables so bad that you would advise to
| never ever do it?

My own experience says that it is a thing best avoiding without a truly
amazing reason not to.

I urge you not to: type(foo) is a very basic Python idiom and you're
breaking it. One day it _will_ bite you or your users. You will
understand, but I would give goods odds that some of your users will not
the day they go to examine the type of an object for perfectly normal
pythonic reasons.

Example: I have a module that stores "objects" and they have as a
primary key a "name" and a "type" - not Python types, just strings.
Accordingly I have a similar situation to yours: the desire to use the
word "type". Fortunately for me, as an attribute in (usually small) code
chunks I can usually go:

  t = foo.type
  ... work with t here ...

Where I must pass one as a parameter I use the common convention of
naming the parameter "type_" at the receiving end.

For the calling end, as in your case, you want to use:


Is it at all possible to make all uses of your "type" function method
calls? Eg:

  something.type("text to type")

It avoids the overloading while keeping your desired name.
Cameron Simpson <cs at>

Wouldn't it be great if all emergency stopping situations occurred on your
favourite bit of'd probably know about it before it happened
and would be able to take other evasive action.
        - Neville Brabet <idiot at>

More information about the Python-list mailing list