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

[Philipp A.]

2013/5/31 Vinay Sajip <vinay_sajip at yahoo.co.uk>

> There have been security issues with YAML (which bit the Rails community
> not
> so long ago) because it allows the construction of arbitrary objects. So it
> may be that YAML is not the best format for scenarios where tools read YAML
> from untrusted sources.
>

please read my post again: i specifically mention that issue and a possible
solution. i’m just a little annoyed that you skipped that paragraph and
attack a strawman now. but not too annoyed :)

The PEP defines the metadata format as a Python dictionary - the serialising
> of metadata to a specific file format seems a secondary consideration. It's
> quite possible that some of the packaging tools that use the new metadata
> will support different serialisation mechanisms, perhaps including YAML,
> but
> ISTM that having YAML in the stdlib is orthogonal to the PEP.
>

but in the future, package metadata won’t be specified in the setup.py
anymore, so we need a metadata file (like setup.cfg would have been for
distutils2). and we write those per hand. the involved metadata corresponds
exactly to the one mentioned here, so what do you think that the format of
that metadata file will be?

Do you have a specific YAML implementation in mind? I thought that the
> front-runner was PyYAML, but in my initial experiments with PyYAML and
> packaging metadata, I found bugs in the implementation (which I have
> reported on the PyYAML tracker) which made me switch to JSON.
>

i didn’t think of any, but i don’t think any available one would meet the
proposed goals of a secure API (like i said in the paragraph you skipped)
and a generator-based implementation/API.

Regards,
> Vinay Sajip
>

regards,
phil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130531/fb153bae/attachment.html>