Tom Lazar asked for a friendlier idiom for mutating elements in Amara. I was reluctant at first because the simpler-on-the-surface idioms he wanted would require rather untidy idioms in the code. I relented to the argument that user convenience comes even before clean code. I finally got around to making and committing the changes today. I'd planned to release Amara 1.0b2 as soon as I'd made these changes, and the timing seems perfect since we've just released 4Suite 1.0b1, but the changes are intrusive enough that I think I'll give folks a chance to try things out from CVS and first see whether it craters for anyone. Please give it a go and give me feedback here or on the mailing list. Thanks.
Here are use cases illustrating the new idioms for Amara. I have added them to the test file mutation.py:
Use case 1:
Source doc: spam
Code: doc.a.b = u"eggs"
Result: doc mutated to eggs
Use case 2:
Source doc: spam
Code: doc.a.b[0] = u"eggs"
Result: doc mutated to eggs
Use case 3:
Source doc:
Code: doc.a.b = u"eggs"
Result: doc mutated to
Use case 4:
Source doc: spamspam
Code: doc.a.b = u"eggs"
Result: doc mutated to eggsspam
Use case 5:
Source doc: spamspam
Code: doc.a.b[0] = u"eggs"
Result: doc mutated to eggsspam
Use case 5:
Source doc: spamspam
Code: doc.a.b[1] = u"eggs"
Result: doc mutated to spameggs
Use case 6:
Source doc: spamspam
Code: doc.a.b[2] = u"eggs"
Result: IndexError
Use case 7:
Source doc: spam
Code: doc.a.b = u"eggs"
Result: doc mutated to spam
Note: attributes take precedence over same name elements in binding. See next use case.
Use case 8:
Source doc: spam
Code: doc.a.b_ = u"eggs"
Result: doc mutated to eggs
In a follow-up entry I'll talk about some other suggestions I've received on this matter.