> In the face of all of this confusion the safest thing would be to make > [...] illegal and then figure it out for Python 2.1. Taking out controversial features is a good idea in some cases, in order to prevent likely disasters. I've heard that the xml support in 2.0b1 is broken, and that it's not clear that it will be possible to fix it in time (the 2.0b1 release is due in two weeks). The best thing here seems to remove it and put it back in 2.1 (due 3-6 months after 2.0). In the mean time, the XML-sig can release its own version. The way I understand the situation right now is that there are two packages claiming the name xml; one in the 2.0 core and one released by the XML-sig. While the original intent was for the XML-sig package to be a superset of the core package, this doesn't appear to be currently the case, even if the brokenness of the core xml package can be fixed. We absolutely cannot have a situation where there could be two applications, one working only with the xml-sig's xml package, and the other only with the 2.0 core xml package. If at least one direction of compatibility cannot be guaranteed, I propose that one of the packages be renamed. We can either rename the xml package to be released with Python 2.0 to xmlcore, or we can rename the xml-sig's xml package to xmlsig (or whatever they like). (Then when in 2.1 the issue is resolved, we can rename the compatible solution back to xml.) Given that the xml-sig already has released packages called xml, the best solution (and one which doesn't require the cooperation of the xml-sig!) is to rename the 2.0 core xml package to xmlcore. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4