On Mon, Feb 27, 2012 at 3:16 PM, Ethan Furman
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