From Ferg.Stephen at bls.gov Tue Nov 2 14:37:24 2004 From: Ferg.Stephen at bls.gov (Ferg, Stephen - BLS) Date: Tue Nov 2 23:14:13 2004 Subject: [Grants-discuss] Python needs a CPyAN Message-ID: I am a very satisfied user of Python and have been for number of years. I would never willing use another language. I wish all good things for Python, and that moves me to express some thoughts about Python's future prospects. I submit that the future expansion of Python usage is constrained by Python's lack of a CPAN-like facility, and I submit that without a CPyAN Python will never even get close to achieving the degree of widespread usage that Perl currently enjoys. In saying this, I am not faulting Python's "batteries included" philosophy or the standard library. The standard library is one of Python's greatest strengths. The standard library is Python's "jewel in the crown" and I whole-heartedly endorse Andrew Kuchling's recent proposal that we focus our energies on improving it. But there are limits to a standard library. You can't put _everything_ into a standard library, nor would you want to. There will always be many specialized modules that shouldn't be put into a standard library, with new modules being developed all the time. These not-in-the-standard-library modules -- let's call them external modules -- are the keys to a language's growth, its popularity, and ultimately its long-term survival. The better the support for external modules is, the more actively that they will be used and (more importantly) re-used. If external module support is good, that makes it easy for developers to create external modules built on top of existing external modules, and then to create even higher-level external modules built on those, until a very large archive of very powerful external modules is created. With such an archive of external modules, it is possible to do very complex, very specialized tasks with only a few lines of code. Note that the key to success is not the size of the archive. CPAN is not a success because it is large. Rather, it is large because it is a success. CPAN is only secondarily a collection of modules. Primarily, CPAN is a set of *capabilities*: capabilities for storing, documenting, checking for updates, searching, downloading, testing, and installing external modules. It includes support for creating module tests and documentation. And it is a social organization -- the CPAN testers group -- that guarantees at least a minimal level of quality assurance for (and therefore trust in) modules in CPAN. CPAN (the library) is large because CPAN (the external module support mechanism) is powerful and easy to use. It is no good saying that Python doesn't need a CPyAN because we've got Google, or we've got SourceForge, or we've got PyPI or distutils or the Vaults of Parnassus. Even used together, all of these tools still fall short of the capabilities of CPAN. Only a full CPyAN will provide the quality and ease-of-use of external modules that will enable Python to flourish in the coming decade. This is _not_ to say that Python will die without a CPyAN. It will certainly survive and thrive. But it will remain a niche language. Without a CPyAN, Python usage and the Python community can never and will never grow to a size that even comes close to rivalling the size of Perl. Some might object that Python is not in a race with Perl, or that popularity and size shouldn't be goals: that smaller and better should be our goal. But I submit that popularity _is_ a goal. Ask any Python programmer what his (or her) first wish is, and you will get the reply: "I wish I could have a job in which I could spend all of my time (or even, _some_ of my time) programming in Python." The only answer to that wish is popularity; such jobs won't exist until Python becomes more popular. (The second wish is an altruistic, professional one: "I wish I could convince my organization to use Python, because Python really is a better technology, and my organization really does need it." And the answer to that wish, too, lies in making Python more popular.) To those who treasure the standard library, and who switched to Python to escape the need to visit CPAN for even trivial things, we can say: that won't change. The standard library will remain as strong as ever; CPyAN will supplement but not replace it. To those who shrink in revulsion from everything Perlish, I say: CPAN is a great system, regardless of who invented it. It is the best thing about Perl. In the great tradition of Python eclecticism, let's steal it! Because a CPyAN is key to the long-term growth of Python, creating a CPyAN should be one of the highest -- perhaps THE highest -- of the Python Software Foundation's priorities. Therefore, I would like to suggest that the Python Software Foundation issue an RFP (request for proposal) specifically for proposals to start building a CPyAN. Building a CPyAN will be a big job, no question. But I think that for the Python community and for the Python Software Foundation, it should be job number one. -- Stephen Ferg (steve@ferg.org) REFERENCES: a very informative post on CPAN by Sean Reifschneider http://groups.google.com/groups?hl=en&lr=&c2coff=1&selm=mailman.983354412.22 606.python-list%40python.org&rnum=6 a post by Hans Nowak http://groups.google.com/groups?hl=en&lr=&c2coff=1&threadm=39D0B743.A60%40hv ision.nl&rnum=8&prev=/groups%3Fq%3D%2522something%2Blike%2BCPAN%2522%26hl%3D en%26lr%3D%26group%3Dcomp.lang.python.*%26c2coff%3D1%26selm%3D39D0B743.A60%2 540hvision.nl%26rnum%3D8 google c.l.p for "something like CPAN" http://groups.google.com/groups?q=%22something+like+CPAN%22&hl=en&lr=&group= comp.lang.python.*&c2coff=1&scoring=d requirements for the catalog SIG http://www.python.org/sigs/catalog-sig/requirements.html