Martin v. Löwis, 20.02.2010 13:08: >> 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).
I would actually encourage Florent to do the opposite: act now and prepare a patch against the latest official ET 1.2 and cET releases (or their SVN version respectively) that integrates everything that is considered safe, i.e. everything that makes cET compatible with ET and everything that seems clearly stable in ET 1.3 and does not break compatibility for existing code that uses ET 1.2. If you send that to Fredrik, I expect little opposition to making that the base for a 1.2.8 release, which can then be folded back into the stdlib. Stefan _______________________________________________ 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
