Holger (of py.test fame) was interested in this technique, so I posted my experience to the py-dev mailing list — which I figured was worth copying here:

The goal is to use a common package name (here: “foo”) for multiple independent modules or packages (“alpha” and “bravo” – to be accessed as foo.alpha and foo.bravo, respectively).

It’s actually rather simple:
The individual components must be contained in a directory named after the virtual namespace, with an __init__.py containing nothing but the following statement:
__import__("pkg_resources").declare_namespace(__name__)
To make Python aware of the local package (e.g. for running tests out of the repository), something like the following is required in a root-level __init__.py:
path = os.path.abspath(VIRTUAL_NAMESPACE)
sys.modules[VIRTUAL_NAMESPACE].__dict__["__path__"].insert(0, path)
This is illustrated here:
http://gist.github.com/231862

Disclaimer: I’m far from being an expert, just sharing what we’ve learned so far (it’s an ongoing effort).

While there are other options, this currently appears to be the most compatible approach (as confirmed by Tarek).

Update: Some further insights made me tweak the approach to module-path mangling.

• programming languages do matter; choice can hugely affect the end result
• whitespace enforcement the “best worst feature” (other languages’ worst features are much more severe)
• Unicode handling is a pain
• lambdas
  • should just be called functions (increases acceptance)
  • cannot contain statements
  • binding issues in loops
• threading is haphazard (GIL is evil) — however: CPython implementation issue, addressed in v2.6 – “it’s different, not necessarily insufficient (e.g. using underlying OS)”
• confusing packaging situation (setuptools, Easy Install, distutils, eggs, buildout, PyPI, virtualenv) – “solved, but people disagree” – “Easy Install sucks, too magic” – “not a Python-specific, but OS-level task” – problem is hard to solve, as there’s a variety of different usage scenarios
• infinity, NaN support (IEEE 754)
• floating point printing (0.1 becomes 0.10000000000000001) — fixed in v3.1
• division — fixed in v3.0
• decorators (“@ is scary, unfamiliar syntax”)
• argument list splicing (e.g. zip(*l)) – “unfamiliar syntax”
• some modules only exist on certain platforms
• positive aspects
  • everything is an object
  • object instantiation (no new keyword – i.e. just like calling a function)
  • generator expressions (from Haskell)
  • chained comparisons (0 < = x < n) - though largely unknown, and allows 0 < x > a or 0 < x in L
  • Iverson’s convention (x < y evaluates to 0/False or 1/True) - "open to abuse"
  • access control (public, private etc.) – not enforced (“advisory [bicycle] locks”) – likely more a social than a technical problem
  • fractions (from v2.6)
  • power (x**2)
  • explicit > implicit (unlike this in JavaScript, for example)
• “Python sucks because sometimes it has to run on Windows”

slides available

Obviously some points were quite controversial (whitespace FTW!) – which is what made the session so interesting.

1. retitled What Sucks About Python in the official program

• minimal, no-API approach; no need for boilerplates
  however, a lot of optional framework-y functionality is provided
• convention over configuration (automatic discovery of test_*.py, def test_*, class Test*)
• py.test overrides AssertionError built-in, then re-runs statement to provide details — avoid assertions with side-effects!
• skip tests only for platform and dependency issues; use @py.test.mark.xfail for “expected to fail”
• funcargs introduced in v1.0 to replace traditional setup methods for fixtures (user & provider, loose coupling); allows for more flexible grouping
• print captured by default, only shown on failure
• internally makes use of its own hook architecture (i.e. many features implemented as plugins)
• yielded tests are deprecated (due to internal ambiguity); recommended to use pytest_generate_tests instead
• interesting plugins: coverage and PyLint integration
• can be used to run non-Python tests (e.g. for JavaScript)
• supports distributed testing (load balancing with multiple CPUs or remote machines, testing on multiple platforms)
• might be renamed (“I wish I’d named it differently”)

Holger Krekel has also published his slides (PDF), which are well worth a look.