On Wed, Feb 22, 2012 at 7:47 AM, "Martin v. Löwis" <mar...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
