On Fri, Aug 16, 2013 at 6:21 AM, Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote:
> PJ Eby <pje <at> telecommunity.com> writes:
>
>> I guess I didn't explain it very well, because that's roughly what I
>> meant: a single namespace for all "extensions", structured as a
>> mapping from group names to submappings whose keys can be arbitrary
>> values, but whose values must then be either a string or a JSON
>> object, and if it's a string, then it should be an export specifier.
>
> Why should the keys be completely arbitrary?
By "arbitrary" I mean only that the PEP doesn't place syntactical
restrictions on them.
> I can't see a reason for this;
> the current constraint of the "prefixed name" seems sufficient. What would
> relaxing this constraint make possible which otherwise isn't?
I think you're thinking I'm describing a single level namespace; I'm
referring to something like this:
{group1: {anykey: export_or_mapping}}
"anykey" is not validated by the spec, only by registered validators
for "group1". Of course it has to have some meaning that is
interpretable by consumers of group1. The point is that the *spec*
only defines the syntax of group names and export strings, and it's
left to specific groups to define the syntax/semantics of the keys.
> On the values: an export specifier is just a more human-friendly version of
> a dict with module/content/extra keys. While of course the uses of
> importables in this area is well established, what specific use cases are we
> enabling by allowing arbitrary JSON? It certainly would clutter the metadata
> and render it less human-readable, and the only thing it provides is a dict
> which could be expressed in an importable form
I gave one example already: i18n/l10n information that's about files
contained in the distribution's data. It's quite possible to have
distributions without any code, only data of that kind. A requirement
to create code, just to specify the data seems rather pointless. In
Nick's reply, he's listed other use cases.
The main question is, should exports and extensions be treated
separately? Nick originally proposed merging the concepts and using
arbitrary JSON. My counterproposal was to say, let's distinguish
exports and extensions by restricting the spec to something which
spells out the distinction.
After this further discussion, I think that the use cases we're
discussing really boil back down to exports vs. metadata extensions,
and that maybe we should stick to them being separate.
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
