> Let's say I'm a web publisher of engineering specifications, and I
> want to use Quixote. The industry body I'm publishing for often names
> documents beginning with the year they were adopted. So, for example,
> "2004 SCADA Extensions". Which seems natural to publish as:
>
>      http://foo.bar/2004ScadaExtensions
>
> Let's say I have 15 or 20 such documents. Not enough to go to the
> trouble of using a database. But too many to stuff into a big
> if-elif-else thing inside of _q_resolve or _q_lookup. That's ugly.

Wouldn't 'documents' of this sort be well handled at the filesystem level,
and then published via StaticDirectory?  Then there are no restrictions
(except those imposed by the underlying FS).  Or if they're too small
individually to warrant separate files, maybe a dict containing all the bits
(in turn handled by a _q_lookup or the like)?  What I really mean is, are
these really appropriate as functions/methods?  I guess my feeling is that
_q_exports is a list of exports, in the literal sense.  Meaning: it's
intended to be a list of callables that are 'exported', much like functions
in a library...  Well, in python, "2004ScadaExtensions" isn't very callable,
considering it isn't even a legal identifier...

I *think* that was the intent of _q_exports.

That said, I don't think there's anything fundamentally wrong with making
Quixote easier to use, as long as the changes don't add more confusion and
overhead than they're worth.  I don't think that's the case here.  Though I
still prefer something a bit more explicit than the tuplized 'mapping'.  No
Magic, and all...  Anyway, it's not likely to hurt me as long as the old
behavior continues to work, though I do wonder slightly about performance
cost of Neil's patch.  (At this point all I'm doing is wondering, since I
haven't tried it, yet.)

just my $.02,

Jason