> > Certainly. The PEP format is a useful one. I've used it myself for some numpy > design documents. But can you see why people might get confused about your > intentions when you call it a draft PEP and post it to python-dev? If you stop > calling it a PEP and stop talking about putting it in the standard library, > people will stop being distracted by those issues.
As I mentioned, I didn't see the fine print in PEP 1 about PEP 2 being the document for library modules. As I mentioned, mea culpa. It is painfully obvious that some don't like the way I have gone about describing the project. They obviously view me announcing this as premature, or presumptuous, or something, and they have some sort of visceral reaction to that. However, I do not believe that any people (other than me) were really confused in the process. I made my intentions clear, and some people reacted badly to that because I didn't follow the process (for which I apologize again). But calling it a draft PEP is a distraction (because of the visceral reaction), but is not really what I would call confusing. My intention actually is to try to build something that is worthy of the standard library, and to eventually try to get it accepted, because I perceive a hole there, with a lot of point solutions being done to solve a common problem, and I believe the pushback is coming from people who fully understood that intention from my posting. I will try to say "hey -- here's a hole in the library and a proposal for how to fix it" more diplomatically and in the correct forum in the future, but it would be disingenuous for me to disown my goal of getting a better configparser into the standard library. Regards, Pat -- http://mail.python.org/mailman/listinfo/python-list