At the last Bay Piggies meeting, as well as at PyCon, Guido felt strongly that no Python Web application framework belonged in the Python standard library for these reasons:
o The release schedule for such a library doesn't match the release schedule of Python. Imagine having to wait a year before an update to the library came out? That'd be unacceptible. o Much of this is a matter of taste. o There's no clear cut winner. Zope and Twisted aren't a part of Python either, despite the fact that they're wildly successful. Perhaps it just doesn't make sense. Best Regards, -jj On 4/29/05, Ian Bicking <[EMAIL PROTECTED]> wrote: > Martijn Faassen wrote: > > 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/jjinux%40gmail.com > -- I have decided to switch to Gmail, but messages to my Yahoo account will still get through. _______________________________________________ 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
