[Python-ideas] PEP 426, YAML in the stdlib and implementation discovery

[Nick Coghlan]

On Sat, Jun 1, 2013 at 2:35 AM, Philipp A. <flying-sheep at 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 at gmail.com   |   Brisbane, Australia