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

[Frank Tobin]

Chris Liechti, on 2002-06-30, wrote:

> 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.

No it doesn't, for two reasons.

1) unittest is merely a testing framework, and there is no standard for 
using it from an extracted archive.

2) unittests are only one way to test; it is generally best suited for
small-unit testing.  I personally use it in conjunction with whole-program
blackbox tests.

Perl also has some fairly standard testing suites, but there is a wide
variety you can choose from.  However, the *interface* from an extracted 
Perl module is *always* "make test".

> 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?

I'm very familiar with docstrings.  Perl also has its POD.  But each of
these is API information.  README's are a different sort.  dostrings do
not substitute for what a README is for:

1) description of the module
2) describes dependencies
3) other information that is not API-oriented

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

Yes, I'm talking about non-bundled extension modules.  That's all we're 
talking about here.  The standard lib is irrevelant to the discussion.

I suggest that you be a Perl programmer for a while, and see what having
CPAN accessible and authoring for it really is like.  You explicitly state
you aren't familiar with it.  I've been author of a couple CPAN modules
for about 4 years now, and an extensive user for just as long, and have
been a Python module writer for just over a year now.  Python is a great
language, but in terms of a reusable code repository, *nothing* comes
close to the jewel that is CPAN.  There is a reason you'll hear this over
and over from people coming to Python from Perl.

The Vaults and PPM just don't hold a candle to CPAN.  For all practical
purposes, they are just big FTP repositories.

-- 
Frank Tobin			http://www.neverending.org/~ftobin/