Mark Janssen wrote:

On Mon, Feb 27, 2012 at 1:22 PM, Ethan Furman wrote:

I should probably correct myself.  It is suiltable, just not
enjoyable.  But now I know you are someone who likes all that arcana
of unittest module.

I'm not sure about *that* -- having to exactly reproduce the output of the interpreter seems kind of arcane to me.  ;)

Well, you're an interesting test case for a theory -- some people shouldn't be coding in python...

Wow.  Talk about mixed emotions -- on the one hand I totally agree with you, on the other I haven't been that offended in quite some time.  ;)

Python, as I see, is "the coder's language".  It's meant for a programmers who want to write code for the sake of their art -- coding for him/herself firstly (and their community) and secondly for "industrial productions" -- shops that just churn out working apps without a consideration for the art.

While Python is the most enjoyable language I have ever used, I strive for mastery and beauty in all the languages I work with.  One of Python's big strengths is it's simplicity, while still allowing for great power (with it's data structures, exception handling, metaclasses (okay, not so simple there ;)).

In the latter case, tests won't be for future coders in your community, but for maintaining "/la machine/"  -- the simple, logical machine in your code.

I fail to see your point here with regards to doctest versus unittest. When I actually write the docs for my dbf module (simple Sphinx generated at the moment), I will have examples in it and run it through doctest.  However, I will still have the unit tests as the primary test bench for it.

As an example, for the dBase III table type there are five field types.  There is a test for a table with each possible combination (not permutation) of one to five of those field types (okay, so I'm slightly paranoid, too ;) -- would you really want to see that in your documentation?

If Python 3 is so hope-dashing, perhaps you should fork your own version?