On Jul 30, 12:06 pm, Rob Beezer <goo...@beezer.cotse.net> wrote: > 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 > cruft, If you want a clean tab completion, simply write the module that implements the thing as my_function_module_implementation.py and then write another module my_function_module_interface.py containing the one line from my_function_module_implementation import function1, function2, function3 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. -- -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
