[Patches] [ python-Patches-1410680 ] Add 'surgical editing' to ConfigParser

Sun Mar 18 04:13:19 CET 2007

Patches item #1410680, was opened at 2006-01-21 00:12
Message generated for change (Comment added) made by anadelonbrin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410680&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Tony Meyer (anadelonbrin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add 'surgical editing' to ConfigParser

Initial Comment:
See also:

[ 1399309 ] ConfigParser to save with order
[ 1371075 ] ConfigParser to accept a custom dict to
allow ordering

The attached patch adds a new method, update_file, to
RawConfigParser.  This method is similar to the
existing write method, but preserves blank lines,
comments, and ordering, as requested many times on
python-dev and python-list.  These are the three
requirements that Guido specified in January 2005.

IMO the attached patch is better than 1399309 because
it includes all the functionality (passing a pointer to
an empty file results in a sorted write() output), but
is completely backwards compatible as write() is
unchanged.    The addition of preserving comments is
also essential for many applications.

IMO the attached patch is better than 1371075 because
the latter really requires a custom class (e.g. the
third party one suggested) in order to be useful.  It
also doesn't address the issue of preserving comments.

The attached patch is essentially a tidied up version
of the one included with SpamBayes (in the
OptionClass.py module), which is used extensively
within SpamBayes (and has been for several years).

Also attached are additional unittests for the new
method, and a documentation patch.

Please let me know if there are recommended changes.

This patch does not address any of the additional
ConfigParser improvements that have been suggested at
various times.

----------------------------------------------------------------------

>Comment By: Tony Meyer (anadelonbrin)
Date: 2007-03-18 15:13

Message:
Logged In: YES 
user_id=552329
Originator: YES

I assume that Paul meant 1371075 and not 131075 was accepted.

1371075 didn't do what Guido wanted at the time this patch was opened (or
have documentation or unit tests), but I guess opinion has changed over
time.

There is incomplete overlap between that patch and this.  This patch is
really about being able to modify a configuration file 'in place', without
losing the ordering or (importantly) comments.  1371075 provides the first
(if you write/find an appropriate ordered dict), but not the second.

However, it seems unlikely that merely preserving comments is enough to
make this change worthwhile.  I have no problem with it being rejected or
being subsumed into some other patch.

----------------------------------------------------------------------

Comment By: Paul Moore (pmoore)
Date: 2007-03-08 02:41

Message:
Logged In: YES 
user_id=113328
Originator: NO

I've looked at the patches attached here. They look reasonable, and in
isolation I would be happy for them to be accepted, although I have no
personal use for the functionality.

However, patch 131075 (ConfigParser to accept a custom dict to allow
ordering) has since been accepted, and in the light of that, this patch may
no longer be appropriate. From the descriptions, and a review of the code,
I am not clear how the two are related. The justification should be updated
to reflect the fact that patch 131075 has been accepted - or if there is no
longer sufficient justification for what may well be a second way to do the
same thing, then this patch should be withdrawn.

I have looked at Scott Dial's updated patches, but I am not clear on what
they add. There has obviously been some discussion which happened off the
tracker - as a result I can't comment on the DEFAULTSECT issue. The
whitespace stripping issue needs a clearer description. I don't see what is
happening here. One or other of the patches is presumably mishandling
leading or trailing whitespace in options, but I can't tell which. The
"growing blank lines" fix sounds sensible.

Recommendation:

1. The OP should review the justification in the light of the acceptance
of patch 1371075.
2. Scott should clarify the issues around the 2 areas I mentioned.
3. An updated patch should be submitted, either by the OP against this
tracker, or by someone else (Scott, perhaps) under a new tracker item,
pointing back to this one.

Otherwise, I would recommend rejection on the grounds that the
functionality now appears to be available via the acceptance of 1371075
(albeit in a form that this patch claims is inferior).

Paul Moore

----------------------------------------------------------------------

Comment By: Scott Dial (geekmug)
Date: 2006-06-08 19:15

Message:
Logged In: YES 
user_id=383208

Before I lose track of the updated patches I made.. They can
be found here:

http://scottdial.com/python-dev/ConfigParser.diff
http://scottdial.com/python-dev/test_cfgparser.diff

The notes I emailed Tony were:

* I have modified the OPTCRE matching to not just throw away
the whitespace after a [=:]. Second, I have modified the
opt.rstrip(), again so that the whitespace isn't just thrown
away. A new variable padded_vi then appears which is a
formatting-preserved version of vi.

* I have removed at least one erroneous write('\n'), and
changed the pattern for adding newlines to missing sections,
such that the newlines are added /before/ the section
heading (and only if there are lines appearing before).
These together solve the growing blank lines phenomena.

* I have modified the add_missing section to deal with
DEFAULTSECT appropriately. Which solves the
appearing/disappearing act that I had mentioned.

* I have updated the test's to match the new expected output. 

---

And in reponse to Jim's comment, such a feature is not in
the scope of the patch. The patch is to explicitly leave
things the way they are, so any sort of sorting would make
no sense.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2006-01-21 04:11

Message:
Logged In: YES 
user_id=764593

Wanting to keep the whole thing (except defaultsection) in 
sorted order will probably be a common use case.

It sounds like you can do this by "updating" to an empty 
file, but it isn't the obvious solution.  Could you either 
add an option to sort the whole thing (so inserts may not be 
at the end) or an explicit mention in the docstring of how 
to get this?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410680&group_id=5470