Hi.

To properly factorise a .cfg I write, I use <=-style section extension. Some of the properties I define would take advantage of += operator, but "[buildout]\nextends = ..."-style extension.

Wouldn't it be convenient if it worked internally to a file as well ?

I've poked around in the code, and found that it's not trivial to implement (calling existing _update_section function is not enough, as that calls "update" on its first parameter and expects values to be pairs). Also, it would create ambiguous outcome when a section would contain <= and its file would extend another file containing an homonym section...

Do anyone have an idea of how to implement this feature ?

The best I could come up with is based on doubling "+" or "-" (rightmost is for "[buildout]\nextends = ..." extension when used, leftmost is for "<="extension) when used. The outcome looks logical enough, but I'm not sure input is clear enough to be The Right Way.

Same-name extends (already works in current code): a.cfg: [foo] color = blue

b.cfg: [buildout] extends = a.cfg

[foo] color += green

Outcome: color = blue green

Different-name extends: b.cfg: [bar] color = red

[foo] <= bar color += green

Outcome: color = red green

Both extends: a.cfg: [foo] color = blue

b.cfg: [buildout] extends = a.cfg

[bar] color = red

[foo] <= bar color ++= green

Outcome: color = blue red green

Another example:

Input as above, except: [bar] color = red green blue

[foo] <= bar color -+= green

Outcome: color = red

Also, a few rants over the current implementation:

1. foo ++= bar is the same as foo += bar (for any number of extra "+") Likewise for "--="

2. foo += bar will create a "foo +" property if [buildout] doesn't contain "extends" (ie, wouldn't it be more consistent to always remove/strip all "+" and "-" ?)

3. foo -+=bar will create a "foo -" property if [buildout] contains an "extends" (and if it doesn't, see 2.). Likewise for "+-=", "+-+=", etc.

4. "foo\t+=bar" (I mean literal tab char) will create a "foo\t" property (because rstrip is called with a parameter which only contains space as a whitespace char)

I'm not saying those inputs make sense. I think current handling gives surprising results, and that alone is bad IMHO.

Regards,