Re: py_cpp, two 'false failures' in test (2.0c1 on Win/NT)

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-10-14 19:04:00

----- Original Message -----
From: "Alex Martelli" <aleaxit_at_[hidden]>

> Hi David,
>
> first of all, my vote for a name for py_cpp is PALIN -- Python Augmented-
> Language INtegration (given that C++ is clearly an augmentation of the
> C Language, the "Augmented Language" bit seems to fit:-).

A bit of a stretch, but it does have a nice ring to it. Thanks!

> More specifically, there are two (incorrect) failure indications running
> test_demo under Win98 (VC++6.0 SP4, BeOpen Python 2.0c1).
>
> One of them:
> Failure in example: ext = Foo('foo')
> from line #17 of test_extclass
> Expected: TypeError: illegal argument type for built-in operation
> Got: TypeError: an integer is required
>
> Clearly, this is just a change in error-message for 2.0c1 (it now
> gives more information).

Oh, this is great! Ullrich and I were just discussing how far we should go
to give better error reporting in cases like this. It's too bad that Python
doesn't tell you which type it actually saw, or what the argument index was
(I realize that's a bit harder). Anyway, this makes contortions on our end a
bit less urgent.

Also, I'm really glad someone is trying this with Python 2.0. I'm actually
rather surprised that it worked as well as it did.

> Not sure how to change the test in
> order to keep passing under older Pythons but also under the
> new one (as the Expected line is currently supposed to give an
> exact-match, I gather).

That's easy, I think. You'll notice several places in test_extclass.py which
use a try/except clause and then assert an re.match() on the error message.
I'll improvise something which I've enclosed in a separate message. Let me
know how it works out.

>
> The other:
> Failure in example:
> assert re.match('<Range object at [0-9a-f]+>', repr(range))
> from line #371 of test_extclass
> Exception raised:
> Traceback (most recent call last):
>   File "doctest.py", line 490, in _run_examples_inner
>     exec compile(source, "<string>", "single") in globs
>   File "<string>", line 1, in ?
> AssertionError:
>
> Arranging to print the repr(range) just before the assert, I
> get: <Range object at 01523FD0>
> so it's just an issue of lowercase vs uppercase -- here, the
> test is easily fixed by just adding to the re.match the flag
> to let it match either case, or, more simply, adding an
> A-F to the range in the brackets in the re.

Thanks, the previously-referenced enclosure should fix that one, too.

>
> A really, really good job, by the way... my heartfelt applause
> to you, and to Dragon Systems for supporting you (I used to
> be in Speech Recognition, with Jelinek's group at IBM Research,
> just when Dragon Systems was getting started [by people
> who had also collaborated with Jelinek earlier, I gathered], so
> I always thought of them as a kind of 'competitors', but, now,
> "all is forgiven"!-).

Wow, thanks! Of course you know who taught me Python at Dragon: Tim Peters,
among others.

> I plan to use it in earnest to expose a good part of the classes
> and functions from the NTL project -- as needed as part of
> the PySymbolic project -- the result will unfortunately be
> GPL-infected (since NTL is GPL) and thus not acceptable as
> part of Boost, but still I hope it can eventually stand as a
> largish, non-trivial example of PALIN use (and configuration
> with VC++6, since that's what I'll use for it...).  If I can be
> of help in some way, just ask!

Oh, wonderful, wonderful! PySymbolic looks really cool. It's great to have
users who want this for serious work. I'm sorry about the GPL infection, but
I guess your work is producing a Python library, and Boost is still
C++-ville anyway.

happy-to-be-taken-seriously-by-real-python-users-ly y'rs,
Dave