doctest, unittest, or if __name__='__main__'

[Roy Smith]

The unpythonicness stems from it being basically a reimplementation of
JUnit, which was designed for use with Java.

JUnit, in turn, is based on a package first implemented in SmallTalk
(http://www.xprogramming.com/testfram.htm).

On stuff like this, I'm not opposed to things being slightly unpythonic.
PyUnit does have some clunkyness to it, but there is some value in having
all the unit test frameworks have a similar feel across languages.
Unfortunately, it has become fashionable to call any sort of unit test
framework "xxxUnit", whether or not it resembles the original or not.

 

[skip]

Paul> The unpythonicness stems from it being basically a
Paul> reimplementation of JUnit, which was designed for use with Java.

I think there are a few modules in Python which suffer that affliction.

Skip

 

[Christoph Zwerschke]

Hi there Christopher, I was wondering if you (or anyone reading this )
could quickly summarize the ways in which unittest is unpythonic, or
point me to somewhere which discusses this.
Is this 'consensus opinion' or mainly your own opinion?

It is just a consequence from the fact that unittest is actually a port
from JUnit (Java) to Python, i.e. a consequence of trying to emulate a
standard framework that many programmers are already familiar with,
which is essentially not a bad idea. However, if you try to counterfeit
Java programming, your code won't be effective or elegant in Python.

Is there a summary somewhere (in addition to the Zen of Python thingy)
of what kinds of things are 'pythonic' and why they are considered so?
I see it referred to a lot, and am starting to get a feel for it in
some areas but not others.

It's probably never been listed completely (and it also changes slowly
as the language evolves). Programming in an unpythonic way is like
driving a nail with a screwdriver. Here are some more explanations:
http://faassen.n--tree.net/blog/view/weblog/2005/08/06/0
http://mail.python.org/pipermail/europython/2005-April/004975.html

-- Christoph

 

[Fredrik Lundh]

It is just a consequence from the fact that unittest is actually a port
from JUnit (Java) to Python, i.e. a consequence of trying to emulate a
standard framework that many programmers are already familiar with,
which is essentially not a bad idea. However, if you try to counterfeit
Java programming, your code won't be effective or elegant in Python.

comparing unittest to py.test (which is from the "almost too clever"
school of pythonic engineering) might be illustrative:

http://ianbicking.org/docs/pytest-presentation/pytest-slides.html

(see the "why not unittest" slide for a list of issues with unittest)

It's probably never been listed completely (and it also changes slowly
as the language evolves).

it cannot be defined, per definition. a good approxmation is "pencil-like
qualities".

</F>

 

[Ben Finney]

http://ianbicking.org/docs/pytest-presentation/pytest-slides.html
(see the "why not unittest" slide for a list of issues with
unittest)

To see many of these points rebutted, see this post:

<URL:http://dirtsimple.org/2005/08/ruby-gems-python-eggs-and-beauty-of.html>

including the comments between PJE (the post author), Ian (py.test),
and Ori (TestOOB).