> 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...
Not sure about the timing, but in case you have not got the message: we should rather drop ElementTree from the standard library than integrate unreleased changes from an experimental upstream repository. > It is qualified as a "best effort" to get something better for ET. Nothing > else. Unfortunately, it hurts ET users if it ultimately leads to a fork, or to a removal of ET from the standard library. Please be EXTREMELY careful. I urge you not to act on this until mid-March (which is the earliest time at which Fredrik has said he may have time to look into this). Regards, Martin _______________________________________________ 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
