-> >>If you need to hang stuff off of binary/octal etc., e.g.
-> >>
-> >>/numbers/15/binary/not
-> >>
-> >>then I'm not sure ;).
-> >>
-> >
-> >This comment gets to my point exactly.  Are the only two ways to chain
-> >namespaces:
-> >
-> >1. import a module or have an instantiated class hanging around
-> >2. _q_lookup
-> >
-> >or is there a third way?
-> >
-> >VanL
->
-> The need to bring in classes and objects just to use _q_lookup seems a bit
-> heavyweight sometimes: it's not always for 'object publishing'.
->
-> Here's a variant of your (2). You could use _q_lookup to refer to another
-> module, rather than an object, passing the "looked-up" value in the
-> _request_ namespace:
->
-> in numbers.py:
->
->      import number_representations
->      ...
->      def _q_lookup(req, name):
->              req.number = int(name)
->              return number_representations

[ munch ]

I do this in Cartwheel a fair bit; it lets me have URLs like

        folder/15/sequence/12

(for sequence #12 under folder #15), where 'folder' and 'sequence
are imported modules.  This lets me have a shallow directory structure:
'folder' and 'sequence' are both top-level modules in my application
package, so e.g. editing 'canal/sequence/__init__.py' lets you modify
the sequence display behavior.

It feels ugly, however, and I am thinking about replacing it with

        folder15/sequence12

and parsing out the ID at the end, which frankly just replaces
confusing non-Quixotic code with crappy localized parsing code ;).

In summary, I guess I'm saying that I don't like this approach, BUT
it works and I don't see a good way around it.  I think I'd probably
go for the class instantiation for a small app.

cheers,
--titus