There are a ton of non-core XML frameworks around for Python, enjoying considerate popularity. The python 'xml' package is not the "one true way" to do XML with Python, and certainly doesn't enjoy anything near the popularity and buzz of Ruby on Rails, say. I don't see why the situation for any higher-level web framework should be different in this respect.
I think the standard library is difficult, because it mixes all sorts of things together. I involves methodology -- very conservative, backward compatible, slow to improve -- which suggests that a package should be at a certain point in its life. It also suggests applicability, that the package should be reasonably generic and not unduly complex. And it encourages people to use it, either directly or indirectly, instead of alternatives. All of these are important, but they are fairly separate. mxDateTime would have been a very capable implementation of date-time objects, and was a de facto standard, but because of methodology conflicts that didn't happen (I assume because mxDateTime had to be released on a schedule determined by commercial concerns). Wx is similar but even worse; there's no practical way I can imagine it going into the standard library, and it's not just inertia, but rather Tk actually *remains* ideal simply because it is largely dead.
Generally the standard library is become much less practical way to move Python forward. Backporting has to be extensive for the library to be viable to use. Up-front design becomes burdensome -- I'm sure there was a lot of useful things that came out of the decimal discussion, but the whole process seemed odd and drawn-out from the outside. Copied designs can shortcut this (e.g., logging), but lead to other design problems. And even as this happens, distributions are often pulling the standard library apart into pieces. Batteries Included has certainly helped me as a developer, but it's not what I have my eyes on for the future.
It would be nice if process and politics could be separated. There's a lot of modules in the standard library that no one should use, even if they aren't marked "deprecated" -- there might be no reason for those modules to go away ever, but they just shouldn't get new users. Similarly there's modules not in the standard library that should be de facto standards, but for good reason can't be part of the standard library development process. But there's no way to suggest that to people except for information question-and-answer sessions in IRC or mailing lists, or the the vague and unpredictable rankings of Google.
"Politics" might be a bad name for this; it doesn't have to be contentious -- for instance, sgmllib has no hero who will be offended that people are steered away from it. But I can't think of a better name. Anyway, I think it might be possible to resolve that issue more easily than the technical issues involved in extending the standard library.
-- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
