[TIP] A rare philosophical thought

[Carl Trachte]

On 8/3/08, C. Titus Brown <ctb at msu.edu> wrote:
> -> I know I am not one of the more hard core developers in this
>
> -> conversation (I am a mining professional), but . .
>  -> Right now, IronPython runs unittest fine.  I work for folks that
>  -> demand use of the dot net framework.  IronPython is as close to that
>  -> as I can get without losing the Pythony goodness we all know and love.
>  ->  Until nose (and coverage tools like figleaf) are available for
>  -> IronPython (correct me if I'm wrong, but it's a major yank to use them
>  -> with that implementation of the language now), unittest is it.
>  -> I'm was never keen on the whole OO or bust philosophy of Java and C#
>  -> myself, but IronPython is written in C#, so folks using that
>  -> implementation of Python *might* (I'm not saying Michael is) be biased
>  -> toward that approach.
>  -> The IronPython tail definitely shouldn't be wagging the CPython dog.
>  -> I guess it's possible to stick with an older version (of unittest) if
>  -> unittest were yanked from Python 2.4 today (I know this is
>  -> impossible).  The code for unittest is still in pure Python.
>
>
> Were a new unit testing system added to the stdlib, it would have to be
>  available in or compatible with the Other Pythons, of course.  (nose and
>  py.test are both written in Python, incidentally.)

I didn't look at py.test, but I messed with nose and module imports in
IronPython.  Where I gave up on nose (for today, at least) was on the
inclusion of setuptools (pkg_resources) in the imports.  PEP 365 had
inclusion of this module in the standard library, but the PEP got
rejected.

It may be possible to implement nose in IronPython, but it's not
something that can be done in an afternoon, at least not by me.  There
are niggling annoyances in doing such an implementation - one example
is the prohibition in IronPython 1.1.1 of assigning (hooking) a
function to sys.exit (you get an error relating to a read only
method).  IIRC, that was in the logging module.  It would involve a
bunch of code tweaks and import hacks to CPython standard library
modules.  This isn't the same as the "not written in pure Python" (I
definitely misstated that), but it is still a barrier of sorts.

unittest, on the other hand, requires the inclusion of 4 or 5 other
modules from the Python 2.4 distro, and it goes off without a hitch.
For now, it's more important for me to test as much of my code as
possible.  After I have done the amount of testing you have, I suspect
I will hate unittest too, and even more :-)

One cool thing about nose is that it can deal with legacy unittest
tests.  So if IronPython does ever work with nose, all those
previously written tests won't have to be re-written.

>
>  ...and I have no objection to unittest remaining in the stdlib.  I don't
>  know that anyone does.

You called it evil, with caps and exclamation marks.  I took it as a
mandate to kill.  Clearly you believe there's a possibility for
redemption.

>
>  -> OK - I've talked myself into a solution:
>
> -> I'm going to store a gold plated usb stick with the code for unittest
>  -> in a deep underground bunker in an undisclosed location so that I will
>  -> never be without my unittest for IronPython . . . You can try to kill
>  -> it, Dr. Brown, but I will keep it here forever . . . Bwahahahaha . . .
>  -> (scary music)
>  -> Apologies for trolling, lack of experience, exaggerated professional
>  -> pragmatism, and general insanity.
>  -> 2 more cents.
>
>
> :)  I'll credit you with one full cent and one half-baked one.

Can the half-baked one be stricken from the record?

>
>
>  --titus
>