On Jul 30, 12:06 pm, Rob Beezer <goo...@beezer.cotse.net
> Then the thing to do would be to write
> my_functions = <full/relative name of the module with the functions>
No, I would think that the module should appear exactly in the spot
where you want the names imported. "import my_functions" would be the
appropriate thing to do, unless there is some architectural reason why
the module cannot occur in the location that would induce the
appropriate namespace name.
> A small amount of experimenting suggests this approach is very compatible
> with tab-completion, which is one of the main features of building such a
> collection. However, tab-completion exposes some irrelevant module-level
If you want a clean tab completion, simply write the module that
implements the thing as
and then write another module
my_function_module_interface.py containing the one line
from my_function_module_implementation import function1, function2,
then my_function_module_interface provides a namespace free from
cruft, at the expense of having to repeat yourself. Note that tab
completion on instances and classes also exposes attributes that have
to do with implementation rather than interface.
> Where should the statement defining my_functions go? Someplace at a
> level above the module itself? In the all.py at that level?
Ideally, nowhere! The relevant "import" already defines them and if
you can ensure that the natural name of the module is the desired one,
no further action is required.
While I agree that tab completion is very useful as a low-cost
documentation tool, I find it a little worrisome if our design
decisions come to be dominated by having tab completion generate
appropriate indices. In lots of cases it will go hand in hand with
writing clean code to begin with (messy namespaces are often a sign of
messy code), but if it forces us to go through strange contortions
(like a separate index namespace module as above) perhaps we have to
rethink our use of tab completion.