[Python-ideas] PEP 426, YAML in the stdlib and implementation discovery

[Masklinn]

On 2013-05-31, at 21:39 , Philipp A. wrote:

> 2013/5/31 Masklinn <masklinn at 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?)