Draft PEP on RSON configuration file format

[Patrick Maupin]

On Mar 1, 11:13 am, Robert Kern <robert.k... at gmail.com> wrote:
> Ignore it. That comment really doesn't apply to this case. That's for things
> that only make sense in the language or standard library, like context managers.
> For libraries like this, Steven's summary is correct. It needs to have a useful
> life as a third party package for a few years before you should propose it for
> inclusion into the standard library. By all means, distribute a design document
> for comment before you implement things; it's a reasonable practice. But don't
> bother with a PEP yet.

So, I went and re-read PEP 1, and in the fine print it directs me to
PEP 2.  Mea culpa -- I though I understood the PEP.

Nonetheless, the fact that I created what I call a "PEP draft" seems
to have had more read into it than I meant.  I will bear this in mind
when I start future projects.  I have a couple of projects, and
contribute to another, which in no way should wind up in the standard
library.  But I find the lack of a good, up-to-date, configuration
reader in the library to be an issue, which is why I had the temerity
to try to start a discussion on what a good standard configuration
file reader should be.

Yes, I would like to create something compelling enough to go into the
standard library. No, I don't expect it to wind up there for a very
long time, if ever.  BUT, at the same time, following the PEP format
is very valuable for my project.  It forces me to think more deeply
about the problem I am solving and it forces me to write down some
documentation.  Really, it's no more burdensome than any other similar
useful template.

Or, to put it another way, it is my goal (which I may or may not be
smart enough to reach) to write a module that anybody would want to
use; that is good enough to put into the standard library.  Whether
this happens or not, one useful tool to help the module down that path
(and produce a better module for me and other users even if it never
becomes part of the standard library) is to think about what it takes
to get into the standard library.  Part of this involves writing the
PEP.  Writing a PEP is a good exercise; the format itself helps me to
focus on important issues.

So I was writing the contents of the PEP anyway, just for me.  The
real question, then, is when to release the PEP (vs. the code).  I've
already got some coding done, but it is not yet good enough to share,
and if there is anybody else out there grappling with the same issues
at this time, I would prefer not to go into production with it until
they have had a chance to look over the design and offer insights and
criticisms.

Best regards,
Pat