On Mon, Apr 05, 2004 at 04:31:11PM -0400, Neil Schemenauer wrote:

> An interesting idea.  A dict is a bit of overkill since I don't
> think it should have more than one entry.  Perhaps a tuple:

Ah, yes, a tuple is better. The point is just to reintroduce the idea
of explicit *mapping* to _q_exports, since that's what it really wants
to be (well, IMO). Disquoting is fine, since it's the common case, but
it's not the only one.

>     _q_exports = ["foo", "bar", ("rdf-model", rdf_model), "baz"]

I could v. easily live w/ that.

> Alternatively, we could have it be purely a rename:
>
>     _q_exports = ["foo", "bar", ("rdf-model", "rdf_model"), "baz"]

Yes, I suspect this changes existing code less. In fact, this is
better than the previous, at the cost of typing 2 extra characters,
because it is likely to be a less invasive change.

> 'rdf_model' would then be looked up the normal way (e.g. it could be
> a package or module).  Another advantage is that you can keep
> _q_exports at the top of the module.  I'm not sure if I like it
> better than the direct function reference version though.

I lean toward the rename rather than direct callable embedding in the
tuple. That's too different than the existing semantics of _q_exports
as I understand it.

My larger point is that either one is a better solution to the URI-Py id
mismatch than doing _q_resolve() or _q_lookup().

In the case where you have many static illegal Py identifiers you want
to export, either the resolve or lookup function solutions require a
crufty if-elif-else thing (or some other bit of mess), when you really
just want an explicit arbitrary name-to-name mapping, rather than the
default disquotation mapping.

Best,
Kendall Clark