Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do we really need LXML? #266

Open
gtback opened this issue Jun 25, 2015 · 1 comment
Open

Do we really need LXML? #266

gtback opened this issue Jun 25, 2015 · 1 comment

Comments

@gtback
Copy link
Contributor

gtback commented Jun 25, 2015

If so, it would be great to document why. Otherwise, we can just use Python's xml.etree.ElementTree.

@chisholm
Copy link
Contributor

chisholm commented Nov 5, 2015

In my opinion, "need", as in "is it a requirement", is a pretty strong statement. No, we don't need LXML. I was able to get python-cybox working (as far as I could tell; all tests passed) with xml.etree without too many changes, with Python 2. (And python-stix and python-maec too.) Python 3 didn't work only because with that version, the etree classes are no longer pure-Python, and I couldn't mark them up with extra attributes.

The core of my strategy for converting from LXML to xml.etree was to add extra attributes to the element nodes, to mimic the extra namespace info LXML adds. That way, all the code would still work, which expected those attributes to be there. And this is why it failed under Python 3. I think it's still possible to make it work, but it would require more extensive changes.

Perhaps the reason LXML is used is because generateDS generates code which uses that package. When generateDS was brought in, LXML came along for the ride and has been there ever since. But I don't know for sure.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants