
From: Masklinn <masklinn@masklinn.net> Sent: Friday, May 31, 2013 1:45 PM
On 2013-05-31, at 21:39 , Philipp A. wrote:
2013/5/31 Masklinn <masklinn@masklinn.net>
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
On 2013-05-31, at 20:43 , Andrew Barnert wrote: 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).
In Philipp A.'s original suggestion, he made it explicitly clear that it should be easily to pick the best-installed, but also easy to pick a specific implementation. And I brought up ElementTree specifically because the same is true there: some people just want the best-installed (the ones who are currently doing the try:/except ImportError:, or would be if they knew about it), others specifically want one or the other. Maybe I didn't make things clear enough with my examples, so let's look at one of them, dbm, in more depth. Plenty of code just wants any implementation of the core API. For that case, you import dbm (or anydbm, in 2.x). But there's also code that specifically needs the traditional 100%-ndbm-compatible implementation. For that case, you import dbm.ndbm (or dbm, in 2.x). And there's code that specifically needs the extended functionality of gdbm, and is willing to deal with the possibility that it isn't available. For that case, you import dbm.gdbm (or gdbm in 2.x). So, what would be the equivalent for ElementTree? Code that just wants the best implementation or the core API can import xml.etree (or xml.etree.AnyElementTree, if you like the 2.x naming better). Code that specifically needs the traditional implementation, e.g., to use _namespace_map, would import xml.etree.ElementTree. Code that specifically needs the extended functionality of lxml, and is willing to deal with the possibility that it isn't available, can import lxml.etree. Notice that this is no change from the present day at all for the latter two cases; the only thing it changes is the first case, which goes from a try/import/except ImportError/import to a simple import. And all existing code would continue to work exactly the same way it always has. So, unless your worry is that it will be an attractive nuisance causing people to change their code to import xml.etree and try to use _namespace_map anyway and not know why they're getting NameErrors, I don't understand what you're arguing about.