On Sun, Feb 28, 2010 at 6:29 PM, Benjamin Peterson <benjamin@python.org> wrote:

In that case, it should live in the user space for several years. If the community decides that it is an excellent format, then it should be considered for inclusion in the stand library.

Agreed. However, there are too many things which became de facto standards without community input this way. PEP 1 itself says: Reference Implementation -- The reference implementation must be completed before any PEP is given status "Final", but it need not be completed before the PEP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code. So, I do not mind the code sitting outside the standard library, and the PEP not reaching "Final" for several years, but I do believe that the PEP process is itself a really good way to build a better mousetrap by consensus. If you do not care to participate in the building of this particular mousetrap, that is OK, too. Regards, Pat

On Sun, Feb 28, 2010 at 7:39 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:

In this case it is *at best* python-ideas material, or even preferably comp.lang.python.

I was thinking about comp.lang.python at some point, but thought I would try here first.

Just for the record, my only reaction when giving the PEP a glance was "yet another configuration file format - yawn".

I suppose I have that sort of reaction about areas I am not interested in, as well, but currently I am deeply interested in configuration files due to my circumstances. In any case, the observation that there are already several preexisting file formats used for configuration is certainly covered in the PEP draft, but if you have anything constructive to add *about* configuration file formats, I would certainly welcome the input. Best regards, Pat

On Sun, Feb 28, 2010 at 7:51 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:

Well, a constructive approach would involve approaching projects which have devised their own formats, so as to know what kind of unified format they would be likely to accept (or not).

Trying to poll "selected projects which have configuration files" may or may not be a constructive approach. Most projects which have predefined formats are unlikely to change, unless there is standardization on a new format. It is very much a chicken and egg problem, although I agree with (and have implemented) the suggestion that I discuss this on python-list. Having said that, one of the reasons I wrote the PEP and am working on a parser is because of a few projects I use and/or am personally involved in. For example, rst2pdf stylesheets are in JSON, e.g. http://rst2pdf.googlecode.com/svn/trunk/rst2pdf/styles/styles.json Now, we're all programmers here, and we can read this, and can even modify it, but it is easy to get wrong, and very verbose with lots of syntax gotchas. For example, unlike Python, JSON won't even let you have a trailing comma. But JSON *is* a great format, and RSON (like YAML) is designed to parse properly formatted JSON, so the goal is that any project which uses JSON could use RSON as a drop-in replacement, and then update its configuration data. Of course, it is extremely easy (hence your yawn) to create a new configuration format, even if it is specified that it is upwards compatible with JSON. The trick is to create the *correct* new format, that at least some people can agree on. In order to do this, I have chosen to poll, not preexisting projects, which have entrenched configuration data and a reluctance to change, but brand new projects which haven't been invented yet. Many of the inventors of those projects hang out on python-dev, so this seemed like a reasonable place to do polling. As I tried to make clear, I will not be too disappointed if I do not come up with something worthy of the standard library for a long time (if ever), but the PEP process is very valuable, and I would like to start off on the right foot by soliciting feedback before I do too much coding. Sorry if it feels like spam; this is my last message on the matter until and unless somebody wants to constructively discuss the actual contents of the PEP. Please feel free to email me privately if you don't want to clutter up this list. Thanks and best regards, Pat

On Mon, Mar 1, 2010 at 3:02 AM, Daniel Fetchinson <fetchinson@googlemail.com

wrote:

Quick question: if JSON is too hard to manually edit, how can RSON be any easier when it is a *superset* of JSON?

Well, Python is essentially a superset of JSON, with string escape handling being ever so slightly different, and using True instead of true, False instead of false, and None instead of null. YMMV, but I find it possible, even probable, to write Python that is far easier to edit than JSON, and in fact, I have used Python for configuration files that are only to be edited by programmers or other technical types. Regards, Pat