On 2/13/06, Clark C. Evans <[EMAIL PROTECTED]> wrote: > If it isn't production quality, it does not deserve to go in the > standard library. If this means not having WSGI in the standard > library, so be it.
There are many different ways to judge "production quality". If we're talking about correct, (standards-compliant, even) code, I wholly agree. If we're talking about having the level of performance, configurability, feature-fullness typically associated with production quality software, I think the standard library is not the place for it. After all, one person's required set of features is another person's feature bloat (and I'm usually that other person :-). Given a particular standard, it's usually not so hard to agree on the most straightforward way to implement it using Python. However, it's *very* hard to agree on the most performant way (since not everybody has the same performance requirements -- e.g. space/time, single/multi-processor etc.), let alone on features and configuration options. This, plus the radically different release cycle needed for production quality software, makes inclusion in the standard library and production quality pretty much mutually exclusive requirements (except for the obvious correctness requirements, which are only a tiny fraction of the set of properties going into production quality). -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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
