Is it OK to re-use the names of Python's built-in functions?

Question

As currently being discussed in this question, I am writing inclusive versions of the built-in range and xrange functions. If these are placed within a module named inclusive, I see two possible ways to name the functions themselves:

1. Name the functions inclusive_range and inclusive_xrange so that client code can use them as follows:

   from inclusive import *
   ...
   inclusive_range(...)
   

2. Name the functions range and xrange:

   import inclusive
   ...
   inclusive.range(...)
   

To me, the second example of client code looks better, but should I avoid re-using built-in names in this way?

Answer 1

This turned into a bit of a list of different options, rather than a straight answer. However, two concepts are paramount:

• Users should be able to replace range and xrange if they explicitly choose to; but
• Users should not be able to implicitly/accidentally replace range and xrange;

it should always be clear to readers of their code where the built-ins are used and where the replacements are used.

For that reason, all options I've outlined below prevent a wildcard import (from inclusive import *) from shadowing the built-ins. Which is the best option for you depends on whether you see replacing the built-ins as a primary or secondary use of your module. Will users generally want to replace the built-ins, or use them alongside each other?

---

In your position, I think I would do the following:

inclusive.py:

"""Inclusive versions of range and xrange."""

__all__ = []  # block 'from inclusive import *'

old_range, old_xrange = range, xrange  # alias for access

def range(...):  # shadow the built-in
    ...

def xrange(...):  # ditto
    ...

This allows users to either:

1. import inclusive and access inclusive.range and inclusive.xrange;
2. from inclusive import range, xrange, clearly replacing the built-ins without any unpleasant side effects; or
3. from inclusive import range as irange, xrange as ixrange to use the built-in and replacement versions alongside one another.

Defining __all__ as an empty list means that from inclusive import * won't quietly shadow the built-ins.

---

If you really wanted to, you could add:

irange, ixrange = range, xrange

to the end of inclusive.py and modify the __all__ definition to:

__all__ = ['irange', 'ixrange']

Now the users have two additional choices:

• from inclusive import irange, ixrange (slightly simpler than manually aliasing the functions as in option 3 above); and
• from inclusive import * (same result as above, still no implicit shadowing of built-ins).

---

Of course, you could go completely the other way - name your own versions irange and ixrange, then if the user really wants to replace the built-ins they would have to:

from inclusive import irange as range, ixrange as xrange

This doesn't require you to define __all__ to avoid a wildcard import shadowing the built-ins.

Answer 2

You should avoid reusing builtin function names in this way, because this can break any libraries that you are depending on and is very confusing for other people (or you in the future) to read and maintain. However, if you must, the option to do so is available to you.

Answer 3

You can, but it is probably not a good idea.

The issue is that if someone else uses the library they may introduce side effects

 from your_lib import inclusive range

 ..... lots of code .....

 range()    # ambiguous 

Answer 4

The problem here is that inside your module you wouldn't be able to call the builtin range() or xrange(). The way you describe inclusive.range() looks good, but any other users might not import in the same way, and they'd get conflicts too.

What about inclusive.irange() and inclusive.ixrange()?

Edit: it's true you would be able to use range() in your own module if you took care to import and rename them, but this is probably another sign that this is a potentially tricky way to go.