I'd give up Perl tomorrow if only...

[Chris Liechti]

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.
> 
> http://testers.cpan.org/
> 
> 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 
tried it?

> 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 
as CPAN)

> 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 
naming conflicts.
python should select one system if it comes to a CPAN equivalent. but the 
current situation has worked very well.

chris

-- 
Chris <cliechti at gmx.net>