On 26 May 2010 13:46, Antoine Pitrou <solip...@pitrou.net> wrote: > This is not what I'm suggesting at all. The stdlib wouldn't shrink > (well, we could dump outdated modules but that's a separate decision).
Ah, OK. In that case, I see the argument for a "Sumo" distribution as weak for a different reason - for general use, the standard library is (nearly!) sufficient, and ignoring specialised use cases, there aren't enough generally useful modules to warrant a "Sumo" distribution (you'd essentially be talking about stuff that "nearly made it into the stdlib", and there's not a huge amount of that). Specialised distributions are another matter - I can see a "web stack" distribution comprising your TurboGears example (or should it be Django, or...?). Enthought essentially do that for a "Scientific Python" distribution. There could easily be others. But a general purpose "Sumo" distribution *on top of* the stdlib? I'm skeptical. (Personally, my "essential extras" are pywin32, cx_Oracle and that's about it - futures might make it if it doesn't get into the stdlib, but that's about all). I'm genuinely struggling to see how a Sumo distribution ever comes into being under your proposal. There's no evidence that anyone wants it (otherwise it would have been created by now!!) and until it exists, it's not a plausible "place" to put modules that don't make it into the stdlib. So (unless I'm missing something) your argument seems to be that if enough good stuff is rejected for stdlib inclusion, this will prompt the people who wanted that stuff included to create a sumo distribution, which addresses the "too many dependencies is bad" argument for inclusion in the stdlib. That sounds like a suspiciously circular argument to me... Paul. _______________________________________________ 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
