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
