On Sat, Jun 1, 2013 at 2:35 AM, Philipp A. <flying-sheep@web.de> wrote:
Hi, reading PEP 426, I made a connection to a (IMHO) longstanding issue: YAML not being in the stdlib.
As MAL already noted, PEP 426 defines a data interchange format for automated tools. Build tools should not (and likely will not) use it as an input format (JSON is a human *readable* serialisation format, but it's a bit of a stretch to call it human *editable* - editing JSON files directly is in some respects even more painful than writing XML by hand). While having a YAML parser in the standard library is a defensible idea, it still wouldn't make any difference to the packaging metadata standards. Those are going to be strictly JSON, as it is a simpler format and there is no technical reason to allow YAML for files that should *never* be edited by hand.
From my perspective, at this point in time, you have 3 reasonable choices for storing application configuration data on disk:
* .ini syntax * easy for humans to read and write * stdlib support * can't handle structured data without awkward hacks * relatively simple * JSON * easy for humans to read, hard for humans to write * stdlib support * handles structured data * relatively simple * YAML * easy for humans to read and write * no stdlib support * handles structured data * relatively complex (Historically, XML may also have been on that list, but in most new code, JSON or YAML will be a better choice wherever XML would have previously been suitable) YAML's complexity is the reason I prefer JSON as a data interchange format, but I still believe YAML fills a useful niche for more complex configuration files where .ini syntax is too limited and JSON is too hard to edit by hand. Thus, for me, I answer "Is it worth supporting YAML in the standard library?" with a definite "Yes" (as a more complex configuration file format for the cases .ini syntax can't readily handle). That answer leaves the key open questions as: * whether or not there are any YAML implementations for Python that are sufficiently mature for one to be locked into the standard library's 18-24 month upgrade cycle and 6 month bugfix cycle * whether including such a library would carry an acceptable increase in our risk of security vulnerabilities * whether the authors/maintainers of any such library are prepared to accept the implications of standard library inclusion. Given the mess that was the partial inclusion of PyXML, the explicit decision to disallow any future externally maintained libraries (see PEP 360) and the existing proposal to include a pip bootstraping mechanism in Python 3.4 (see PEP 439), I have my doubts that Python 3.4 is the right time to be including a potentially volatile library, even if providing a YAML parser as an included battery is a good idea in the long run. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia