I'd give up Perl tomorrow if only...
cliechti at gmx.net
Sun Jun 30 17:45:43 EDT 2002
Frank Tobin <ftobin at neverending.org> wrote in
news:Pine.LNX.4.44.0206301550120.7807-100000 at palanthas.neverending.org:
> Christopher A. Craig, on 2002-06-21, wrote:
>> Given the hardware and bandwidth, it shouldn't be all that hard to
>> create a CPAN for Python. I suspect one of the main reasons it
>> hasn't been done is that Google works so well.
> I don't think you have a good grasp of what CPAN really is. It's much
> more than simply a big FTP site.
> The key thing about CPAN is not only the breadth of modules it has,
> but the strong testing system they employ, namely cpan-testers. I am
> the author of a module on CPAN, and it's great to be able to upload
> module, and have it tested on a diverse set of architecures.
> Note that in order to have something be as successful as cpan-testers,
> modules needs to have:
> 1) a standard extraction mechanism (Perl and Python do have)
> 2) a standard testing mechanism (Perl has ('make test'), Python doesn't)
well it has. the module unittest provides all thats needed. the module just
needs a class derrived from unittest.TestSuite and the unittest module can
find the tests.
its also a convention to have a test() function, but the former is more
powerful. yes, it should be used more widely.
> 3) a standard installation mechanism (Perl and Python do have)
> 4) a standard README system (Perl has, Python doesn't)
i don't know the perl way but with python every object has a __doc__
attribute, every module, class, function and method etc. and with pydoc
there is a standard extraction tool right in the standard distro. ever
> What is most missing for Python is a standard testing suite system.
> And until it gets this, it's pretty much not possible to get anything
> close to the quality of CPAN with cpan-testers.
as metioned above, python has all it needs, now if you talk of an
organization that runs test on non-standard extension modules, no we don't
have that right now. the python distro has good tests for the standard lib,
but as there is no organization that distributes extensions, everyone is
responsible for testing its modules. (there are collections of modules,
like The Vaults of Parnassus: http://www.vex.net/parnassus/ or ActiveStates
Programmer's Package Manager (PPM) but thats not as strong or established
> Another great benefit of CPAN is that the modules on it are somewhat
> 'sanctioned'. Sure, it doesn't take much to get onto CPAN, but the
> difference between the 'something' it does take, and 'nothing', is
> enormous in speaking for the quality of the modules you'll find in
> contrast to searching Google and coming across Joe Schmoe's Python
> module. A similar scenario is comparing random RPM's you might find on
> Google to FreeBSD/Gentoo's ports trees; the centralization somewhat
> sanctions the software, and this is critical, IMO.
agreed, but nothing aginst non registed modules, found on google etc... not
everyone likes the work to get a module registerd but it might be of great
quality and right the thing one needs.
> Furthermore, I find the de-facto multi-tier naming system that Perl
> employs for modules to be a good thing; it encourages users dividing
> up their modules in the global namespace. This is critical for
> finding what you need. For example, I can go into the DBD branch on
> CPAN and find every database driver it has. Python doesn't have an
> equivalent (packages just aren't the same thing; they are owned by
> 'one' thing, most of the time).
thats one solution, java uses the reversed URL of the company to avoid
python should select one system if it comes to a CPAN equivalent. but the
current situation has worked very well.
Chris <cliechti at gmx.net>
More information about the Python-list