On Mon, Feb 27, 2012 at 3:16 PM, Ethan Furman <ethan@stoneleaf.us> wrote:
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. ;)
Haha, okay. Sorry, I was a bit blunt there.
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 ;)).
Have you seen Ada, Oberon? For some reason I couldn't begin to describe, I
think you might actually like them better. But, hey, I'm happy there're
people who enjoy python.
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.
Hmm, I guess you're kind of a hybrid, then...
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?
No, you are right there. But this look's like a case of hybridized code --
you aren't able to make doctests at a fine-enough granularity in order to
ensure your code so they go up a level of abstraction where it gets bulky
and no longer self-documenting.
If Python 3 is so hope-dashing, perhaps you should fork your own version?
Well, I still have hopes for it, it's just still in progress...
I appreciate your reply,
mark
Mark Janssen