Martin Maney wrote:

> Oh, it is simplicity itself.  Rather than adding an unobvious kluge to
> _q_exports, add an interface that is explicitly for mappings.  Perhaps
> _q_map isn't a sufficently obvious name for it?

Adding an additional _q_ attribute would be far less obvious than
tweaking the syntax of the very well-known _q_exports attribute. (Yes,
there's a semantic adjustment too, but it's ever-so-slight.) There are
already too many of them!

I don't really get why there's such harsh sentiment about putting tuples
in _q_exports. It's precisely not magic: the behaviour would be
explicit, and could be explained clearly in a single sentence of
documentation. Also, _q_exports serves an important secondary function
as a declarative precis of a module and its capabilities. I'd like to be
able to "read" as much as possible about a module by looking at its
_q_exports, and I think this "kluge" could be useful in that regard.


But having said that, is there anything particularly wrong with this?


     import foo, bar, baz
     import _twenty_foo, _twelve_bar, _shebang


     _q_exports = ['foo', 'bar', 'baz']

     _other_exports = {
         '20foo':    _twenty_foo,
         '12bar':    _twelve_bar,
         '#!':       _shebang,
     }


     def _q_resolve(name):
         return _other_exports.get(name)

     ...

It's clean, explicit, declarative, easy to type, and has a nice
idiomatic feel about it, don't you think? I would happy reading this in
someone's code, or writing it in mine.

...Yeah, I like this better. Negate my original +1.

-- Graham