Take the 2-minute tour ×

Is this a good practice in Python (from Active State Recipes -- Public Decorator)?

import sys

def public(f):
  """Use a decorator to avoid retyping function/class names.

  * Based on an idea by Duncan Booth:
  * Improved via a suggestion by Dave Angel:
  all = sys.modules[f.__module__].__dict__.setdefault('__all__', [])
  if f.__name__ not in all:  # Prevent duplicates if run from an IDE.
  return f

public(public)  # Emulate decorating ourself

The general idea would be to define a decorator that takes a function or class and adds its name to the __all__ of the current module.

share|improve this question
Fixed the title, as some people pointed out –  Ed L Jun 1 '11 at 18:57

4 Answers 4

up vote 3 down vote accepted

Yes, it's a good practice. This decorator allows you to state your intentions right at function or class definition, rather than directly afterwards. That makes your code more readable.

def foo():

class bar():

class helper(): # not part of the modules public interface! 

Note: helper is still accessible to a user of the module by modulename.helper. It's just not imported with from modulename import *.

share|improve this answer
I wouldn't necessarily say it's a good practice outright. The advantage of having an __all__ explicitly defined at the beginning of a module is that anyone (possibly you) looking at it can very easily determine what is exported via import * and what is part of the public API of the module. Using a public decorator makes this much more difficult. However, if you use a decorator, you can tell while looking at a member of the module whether it is in __all__ or not. So both have their respective pros and cons. –  darkfeline Mar 19 '13 at 23:58
Everything darkfeline said plus - it breaks intellisense/code-completion on IDEs with naive code tokenizers. –  synthesizerpatel Nov 30 '13 at 5:06

The more idiomatic way to do this in Python is to mark the private functions as private by starting their name with an underscore:

def public(x):

def _private_helper(y):

More people will be familiar with this style (which is also supported by the language: _private_helper will not be exported even if you do not use __all__) than with your public decorator.

share|improve this answer
This doesn't seem to address the problem the decorator solves: keeping the names in __all__ up to date. –  Ed L Jun 1 '11 at 20:18
@EdL That's because if you consistently use underscores for "private" things and no underscores for public things, you won't need __all__ at all –  Tobias Kienzler May 15 '13 at 8:02

I think the question is a bit subjective, but I like the idea. I usually use __all__ in my modules but I sometimes forget to add a new function that I intended to be part of the public interface of the module. Since I usually import modules by name and not by wildcards, I don't notice the error until someone else in my team (who uses the wildcard syntax to import the entire public interface of a module) starts to complain.

Note: the title of the question is misleading as others have already noticed among the answers.

share|improve this answer

This doesn't automatically add names to __all__, it simply allows you to add a function to all by decorating it with @public. Seems like a nice idea to me.

share|improve this answer
By automatically, I basically meant w/o typing the name in the list explicitly –  Ed L Jun 1 '11 at 18:57
Yes. (11 more characters to go) –  LaC Jun 1 '11 at 19:18

Your Answer


