Not enough Python library development [was PEP scepticism]

[Roman Suzi]

On Tue, 3 Jul 2001, Grant Griffin wrote:

>Roman Suzi wrote:
>>
>...
>> CPyAN is much more complex task, because there are:
>...
>
>I think the problem here might be one of marketing, combined with a lack
>of corporate sponsorship.  To that end, I propose this resource be
>called "Python Program Archive Network", or PyPAN, for short. That might

Maybe PyCAN ;-)
(C for components)

>help it attract funding from Mrs. Smith's and Sara Lee.  (Heck, if
>nothing else, maybe those ladies can contribute something tasty to the
>Python Cookbook.)
>
><sorry>
>
>Seriously, folks, I never was a big fan of CPAN: in fact, for me, it was
>just another part of my overall poor user-interface experience with Perl
><wink>.  Although CPAN is impressive in terms of sheer girth, the CPAN
>concept seemed to encourage large interdependencies between modules.
>Although this seems like good thing in some ways (because it indicates a
>lot of software reuse), I found it nightmarish to install even fairly
>simple packages.  (I never could get the automatic CPAN installer gizmo
>to work well--at least without giving it a great deal of manual help.)
>
>Having a very large standard library seems a better solution.  (Of
>course, Perl also comes with a large standard library.)  I never seem to
>have large cross-package dependency problems with Python; my experience
>has been that nearly all packages require zero or one other packages.
>Presumably, this is a fortunate aftertaste of the fact that PyPAN is
>still just a half-baked idea.

I do not think large standard library is a must.  Probabaly, there could
be uniform way to download missing components and probably bare Python
distribution could contain a references of modules which could be
downloaded if user need them.

This will solve problem with large initial download of lots of unneeded
things.

>But maybe an increasingly large standard library isn't totally
>practical.  An alternative that I think would be very helpful is
>"application-targeted" distributions.  For example, someone could make a
>"Numeric" bundle of Python, including NumPy and related modules;
>likewise, there could be a "webmaster" bundle.  Of course, this takes a
>lot of time and effort for somebody to create and maintain.
>(ActiveState folks, are you listening?--given that you somehow make
>money by giving away software, the more software you give away, the more
>money you'll make <wink>.)

Its the way of Slackware Linux:
they thought the same way and labeled packages as "A", ... "K", "X" ,...
package-sets.

The better way is that of rpm or apt-get enabled distros.

The problem is the lack of knowledge.
There need to be some central storage + mirroring network
and mentioning PyPAN contents in the core Python distribution
(with links and such).

Sincerely yours, Roman Suzi
-- 
_/ Russia _/ Karelia _/ Petrozavodsk _/ rnd at onego.ru _/
_/ Wednesday, July 04, 2001 _/ Powered by Linux RedHat 6.2 _/
_/ "Mediocrity requires aloofness to preserve it's dignity" _/