[Python-ideas] Stdlib YAML evolution (Was: PEP 426, YAML in the stdlib and implementation discovery)

[anatoly techtonik]

On Wed, Nov 13, 2013 at 9:47 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 13 November 2013 17:15, anatoly techtonik <techtonik at gmail.com> wrote:
>> On Mon, Jun 3, 2013 at 3:59 AM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
>>> David Mertz writes:
>>>
>>>  > I would definitely like to have a YAML library--even one with
>>>  > restricted function--in the standard library.
>>>
>>> Different use cases (and users) will stick at different restrictions.
>>> This would be endlessly debatable.  I think the only restriction that
>>> really makes sense is the load vs. load_unsafe restriction (and that
>>> should be a user decision; the "unsafe" features should be available
>>> to users who want them).
>>
>> Short version of previous letter. "yamlish" is only for simple nested
>> human editable data, such as config files. Format is based on widely
>> popular "organic" examples found on internet and provided in previous
>> letter:
>
> 1. Inventing a new data format (your "yamlish" format) is probably a
> bad idea. There are enough already.
> 2. Putting support for a newly designed format directly into the
> stdlib is *definitely* a bad idea.

It is not a new format. It is YAML subset, limited but fully readable and
parseable YAML. If you read it with YAML then save back immediately,
you will get the same result.

> Write a module, put it on PyPI, If it's useful, people will use it.
> They will help you to iron out the design of the new format - it may
> evolve into "full" YAML or into JSON, in which case you've learned
> something about why those formats made the compromises they did, or it
> will evolve into a popular new format, at which point it might be
> worth proposing that the module is ready to be included in the stdlib.
> Or it will not be sufficiently popular, in which case you have at
> least solved your personal problem.

Can you more thoroughly criticize the idea, instead of sending me
somewhere where I will definitely fail.

I've written a few parsers in my life, all manual - I don't have much
experience with flex/yacc kind of things, that's why I asked if anybody
known a good framework for such stuff.

That's why I asked if there is a comparison site similar like
http://todomvc.com/ for MV* frameworks, but for Python parser
frameworks. Yes/No/Don't Care/Ignore.

I don't believe that that among python-ideas subscribers there are no
people with experience in different parser frameworks.

It is also a good Google Code-In, GSoC project.

> If you are expecting someone else to do this, I think the general
> message from this thread is that nobody else is interested enough to
> take this on, so it isn't going to happen, sorry.

The python ideas list is useless without people looking for an exercise
and that's worthy implementing regardless of who gave the idea. Good
idea without implementation is the same zero as bad idea with.

Communicating and defending ideas alone is time-consuming, hard and
thankless process already. Even if you come up with implementation
for something like hexdump, it will likely be rewritten without any credits
if you won't accept the hecking CLA, which nobody cares to explain
even on python-legal.