On Wed, Nov 13, 2013 at 9:47 PM, Paul Moore email@example.com wrote:
On 13 November 2013 17:15, anatoly techtonik firstname.lastname@example.org wrote:
On Mon, Jun 3, 2013 at 3:59 AM, Stephen J. Turnbull email@example.com 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:
- 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.