On 2013-05-31, at 21:39 , Philipp A. wrote:
2013/5/31 Masklinn <masklinn@masklinn.net>
On 2013-05-31, at 20:43 , Andrew Barnert wrote:
try: from lxml import etree as ET except ImportError: from xml.etree import ElementTree as ET
Your registration mechanism would mean they don't have to do this; they just import from the stdlib, and if lxml is present and registered, it would be loaded instead.
That seems rife with potential issues and unintended side-effects e.g. while lxml does for the most part provide ET's API, it also extends it and I do not know if it can run ET's testsuite. It also doesn't handle ET's implementation details for obvious reasons.
and that’s where my idea’s “strict API” comes into play: compatible implementations would *have to* pass a test suite and implement a certain API and comply with the standard.
But that's not sufficient is the issue here, as I tried to point out when somebody uses ElementTree they may be using more than just the API, they may well be relying on implementation details (e.g. namespace behavior or the _namespace_map). It might be bad, but it still happens. A lot. Hell, I've used _namespace_map in the past because I had to (wanted to transform a maven script and some script down the line, maybe maven itself, wanted exactly the `mvn` namespace alias). This will usually be safe, especially with old packages with low to no evolution. But if you start swapping things with "API-compatible" libraries all bets are off.
unsure if and how to test the latter (surely running a testsuite when something wants to register isn’t practical – or is it?)