I've decided I'm really not happy with the current approach to extension fields in PEP 426. It's ugly, clunky, inflexible and is hard to cleanly convert to more structured metadata.
Here's the current example from the PEP: Extension: Chili Chili/Type: Poblano Chili/Heat: Mild Here's what I'm thinking of changing it to: Extension: Chili Chili/json: { "type": "Poblano", "heat": "Mild" } So rather than allowing *arbitrary* additional headers as it does now, an Extension declaration would allow only one new header: <extension-name>/json That would then allow arbitrary embedded JSON (so long as you still follow the "no blank lines, because that 's the end of the headers" rule) When converting the entire metadata definition to JSON for subsequent processing, the extensions fields would then cleanly convert from multiple extension entries to something like: "extensions": { "Chili": { "type": "Poblano", "heat": "Mild" } } The other area where I think such an "embedded JSON" approach could work is coming up with a clean format for an Entry-Points field. Specifically, I am thinking of proposing the setuptools.setup inspired: Entry-Points: { "console_scripts": { "foo": "my_package.some_module:main_func", "bar": "other_module:some_func" }, "gui_scripts": { "baz": "my_package_gui.start_func" } } Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig