On Mon, Sep 14, 2009 at 12:07 PM, C. Titus Brown <c...@msu.edu> wrote:
> I'd like to -1 this whole discussion by saying that you guys are basing > this whole thing on your mature, competent skills of Python programming > and computer use. Corporations and beginning programmers need something > straightforward, simple, with "batteries included" in order to do > something sane with Python in large multi-user environments. And just to hit on this specifically: Actually, I'm not. Try explaining what modules in the stdlib are of questionable use, and why not to use them to your boss, who is learning Python. Them: "Why shouldn't I used httplib?" Me: Reasons A,B,C - just use httplib2 Them: "Why don't they just fix that?" That's for starters. If you want batteries included to mean something more than "we got junk in our trunk" then we should raise the bar. Not to mention over 216 modules? Less than a handful of active committers? It's not sustainable. > We can discuss *which* batteries should be included -- bsddb was taken > out, sqlite3 looks like a long-term winner -- but IMVSO pruning the > stdlib should not be seriously consider until we have an excellent, > time-tested, battle-proven completely automatic package installation > system. Pruning must occur regardless of how easy it is to install something "voted off the island". > To me, this could be like the decision to simultaneously release python > 3.x and python 2.x distributions, but much worse: even more confusion- > engendering and detrimental to short- and medium-term adoption of > Python. All an end user sees: click here to download Python 3.0-Full *smaller print* click here for the interpreter-core *smaller print* click here for the stdlib Otherwise, they will see the eventual deprecation of things which are *broken* or have *no tests* to even prove if they aren't between releases. jesse _______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
