[Python-ideas] Fwd: doctest (and.... python3000)
dreamingforward at gmail.com
Mon Feb 27 23:25:14 CET 2012
On Mon, Feb 27, 2012 at 3:16 PM, Ethan Furman <ethan at 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
> 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,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas