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

[Philipp A.]

2013/6/5 Stefan Drees <stefan at drees.name>

> Now that Kirill gave some input and posed some questions, we might be
> better discussing how to proceed with YAML (as this seems a complicated
> enough beast).
>
> What do you think?
>

yes. so there are no objections to those tentative API cornerstones?

   1. “load” is PyYAML’s safe_load
   2. PyYAML’s “load” will require specifying a kwarg to “load” or gets a
   longer toplevel name
   3. there is a “load_iter” which yields documents from a stream – also
   possibly a “load_all”, but maybe that’s just “list(load_iter(…))”
   4. similarly: we should supply a dump function that interacts well with
   streams<https://bitbucket.org/xi/pyyaml/issue/6/load_all-dump_all-do-not-work-well-with>

what i’m unsure of: should “load” and “dump” determine if the input arg is
a string or a file object, or should we supply “loads” and “dumps”? i
prefer the former, since i can’t thing of a case where there’s a doubt
which is which, but obviously someone decided to use the “…s” versions for
the stdlib json module, so maybe there’s a reason…?


then for implementation, if possible, we should use PyYAML, and modify it
to our needs (e.g. fully implement YAML 1.2 if that isn’t too much, fix
bugs, and change the API.)

also we have to discuss on how and if we want to include the C
implementation. PyYAML’s mechanism is to use “Loaders” explicitly, but
people are surprised and dissatisfied <http://pyyaml.org/ticket/34> with
that. if we include a C implementation, should we implicitly use it when
the user imports yaml?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130605/2d9f3a16/attachment-0001.html>