Merge lp:~gz/bzr-xmloutput/relocate__escape_cdata into lp:bzr-xmloutput
Status: | Merged |
---|---|
Approved by: | Guillermo Gonzalez |
Approved revision: | 147 |
Merged at revision: | 147 |
Proposed branch: | lp:~gz/bzr-xmloutput/relocate__escape_cdata |
Merge into: | lp:bzr-xmloutput |
Diff against target: |
187 lines (+35/-21) 8 files modified
__init__.py (+1/-2) annotatexml.py (+3/-2) logxml.py (+4/-2) lsxml.py (+4/-3) statusxml.py (+5/-6) versionxml.py (+2/-1) writer.py (+10/-0) xml_errors.py (+6/-5) |
To merge this branch: | bzr merge lp:~gz/bzr-xmloutput/relocate__escape_cdata |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Guillermo Gonzalez | Approve | ||
Review via email:
|
Commit message
Import xml escaping function through local module without relying on bzrlib elementtree monkey-patched version
Description of the change
In fixing bug 614522 I removed the monkey-patching artefact of a copy of the elementtree _escape_cdata function from bzrlib.
Despite being blasé about how easy this is to fix to Vincent, I got pretty stuck last night trying to create a branch that didn't change code all over the place.
It was sort of a choice between:
* Expand every import of _escape_cdata to look in all *three* locations elementtree may live.
* Stop using relative imports everywhere and just do the import dance in the base package, and import from there using bzrlib.
* Write a new escaping function somewhere and use that, the elementtree one isn't really sufficient anyway.
* Import from elementtree via bzrlib.
* Make a new module to put the import dance in and import from there.
In the end, this branch does the last two, plus pokes a few imports statements that I couldn't resist nearby.
There are some bits of code I had in this branch, but I have not included here:
* Fixing the Python 2.5ism in test_info_xml.
* Teasing out the needlessly lazy imports from the helpful ones in the base package.
* Importing from bzrlib.
* Some more import cleanup.
* Creating xml prolog function rather than having the same user encoding inserting logic in lots of places.
* Making the prolog use an encoding expat can actually parse.
I can put up branches for any of these that there's interest in landing, but what I'd really like to see, and haven't coded, is a sane abstraction for writing xml that actually ensures well-formedness.
Still unresolved, ElementTree 1.3 (used in Python 2.7) makes the encoding parameter non-optional, for good reason, so this wants changing to something better sooner rather than later.
Wow, this looks great.
Thanks a lot for putting this together.
Yes, there is interest in any improvement/ fix/code cleanup you might have in mind (or already coded ;-))
And I agree with you on most of the exposed above, mostly on the need of a unified way to generate the xml (or json, or protobuf or <another format of your choice>).
I'm a bit short on time (as the commit log shows) :-(
But I hope to get back to work on bzr-xmloutput and bzr-eclipse in the short term again.