[Python-Dev] folding cElementTree behind ElementTree in 3.3

[Nick Coghlan]

On Wed, Feb 22, 2012 at 7:47 AM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> Am 21.02.2012 11:41, schrieb Eli Bendersky:
>> I can't fathom why someone would do it though, since bar tiny
>> differences (like this one) cET is just a faster ET and it's available
>> practically everywhere with CPython. I mean, is it really important to
>> be able to subclass ET.Element? What goal does it serve?
>
> Statements like this make me *extremely* worried. Please try to adopt
> a position of much higher caution, accepting that a change is
> "incompatible" if there is a remote possibility that someone might
> actually rely on the original behavior. Otherwise, I predict that you
> will get flooded with complaints that you broke ET for no good reason.

Indeed. It's a *major* PITA at times (and has definitely led to some
ugly workarounds), but we have to take documented API compatibility
very seriously.

We're often even reluctant to change long-standing *de facto*
behaviour, let alone things that are written up in the docs as being
explicitly supported. In Python 3, merely saying "this class" or "this
type" is as good as saying "this instance of the type metaclass" as
far as API guarantees go. That's the reason for the awkward phrasing
in the functools docs - specifically to *avoid* saying that
functools.partial is a class, as we want to allow closure-based
implementations as well.

The key thing to remember is that the web-style "eh, just change it,
people can fix their code to cope" mentality is a tiny *minority* in
the global software development community. There's a huge amount of
Python code out there, and a lot of it is hidden behind corporate
firewalls. Our attention to backward compatibility concerns is one of
the reasons why Python's reach extends into so many different areas.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia