On Jan 19, 2012 9:28 AM, "Bill Janssen" <jans...@parc.com> wrote: > I'm not sure how much of a problem this really is. I continually build > fairly complicated systems with Python that do a lot of HTTP networking, > for instance. It's fairly easy to replace use of the standard library > modules with use of Tornado and httplib2, and I wouldn't think of *not* > doing that. But the standard modules are there, out-of-the-box, for > experimentation and tinkering, and they work in the sense that they pass > their module tests. Are those standard modules as "Internet-proof" as > some commercially-supported package with an income stream that supports > frequent security updates would be?
This is starting to sound a little like the discussion about the __preview__ / __experimental__ idea. If I recall correctly, one of the points is that for some organizations getting a third-party library approved for use is not trivial. In contrast, inclusion in the stdlib is like a free pass, since the organization can rely on the robustness of the CPython QA and release processes. As well, there is at least a small cost with third-party libraries for those that maintain more rigorous configuration management. In contrast, there is basically no extra cost with new/updated stdlib, beyond upgrading Python. -eric > > Perhaps not. But maybe that's OK. > > Another way of doing this would be to "bless" certain third-party > modules in some fashion short of incorporation, and provide them with > more robust development support, again, "somehow", so that they don't > fall by the wayside when their developers move on to something else, > but are still able to release on an independent schedule. > > Bill > _______________________________________________ > 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/ericsnowcurrently%40gmail.com
_______________________________________________ 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
