Martin v. Löwis <martin <at> v.loewis.de> writes: > > > If the goals of Python ElementTree and Fredrik ElementTree diverge I don't > > see a problem with an amicable fork. > > I see one: Fredrik will not consider such a fork amicable. Of course, if > you could make him state in public that he is fine with a procedure that > you propose, go ahead. He had stated in public that he is fine with the > procedure I'm defending right now, that's why I'm defending it: no > substantial changes without his explicit approval (breakage due to > language changes is about the only exception - not even bug fixes are > allowed).
Actually this should not be a fork of the upstream library. The goal is to improve stability and predictability of the ElementTree implementations in the stdlib, and to fix some bugs. I thought that it is better to backport the fixes from upstream than to fix each bug separately in the stdlib. I try to get some clear assessment from Fredrik. If it is accepted, I will probably cut some parts which are in the upstream library, but which are not in the API 1.2. If it is not accepted, it is bad news for the "xml.etree" users... It is qualified as a "best effort" to get something better for ET. Nothing else. -- Florent “Nobody expects the Spanish Inquisition!” _______________________________________________ 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
