Hi Greg,
Greg Ewing wrote:
> Stefan Behnel wrote:
>> Wouldn't special casing a type test for builtins and extension classes be
>> better here than adding new functions?
>
> I'm not sure what you mean by that. There's no run-time
> distinction between a builtin class, an extension class
> implemented with Pyrex, or an extension class created some
> other way. They're all just types.
I didn't mean at runtime. The compiler knows how to distinguish them.
> I could make the Pyrex version of isinstance() behave
> differently, but then it wouldn't have quite the same
> semantics as it does in Python. That could be confusing,
> especially since you aren't guaranteed to be always
> getting the directly-called version.
I could live with different semantics even in this case:
allowed_type = ExtType
print isinstance(obj, allowed_type) # Python semantics
and
print isinstance(obj, ExtType) # non-Python semantics
The Pyrex/Cython semanics would be:
- testing for an explicitly named extension type or builtin type would give
you a direct (sub-)type check (maybe even for tuples of subtypes? It would be
nice to optimise that as well)
- testing for a runtime type will fall back to Python semantics.
I think those are the perfect semantics for the context of Pyrex/Cython.
Besides, the actual difference of allowing or disallowing a type override
through ".__class__" is so tiny that almost no user will actually notice, and
those who need that distinction can well be asked to use a somewhat less
straight forward syntax. That's much better than forcing users to use a
non-standard function for the much more likely case that they do the type test
to make sure you can rely on a specific struct layout. One of the major use
cases of Pyrex/Cython is wrapping external libraries with Python classes,
after all.
> Rather than fiddle with the semantics, I felt it was
> better to provide different functions -- EIBTI and
> all that.
I would be fine with that if the new function was for the less common case.
But I would say it's for the most common case, which would better be handled
by the normal function that is named as in Python.
>> So if you added doctests
>> to your test modules (as we do for ours), you could still validate the
>> resulting source code for Pyrex, but we could both join forces and
>> benefit
>> from a growing test suite.
>
> Okay, so you just want me to run the Cython tests as
> well. That shouldn't be too hard.
Sort of. I just want to avoid doubling the work on both sides. After all, I
prefer investing more time into the compiler than into the test suite.
> Is there somewhere I can download them from?
Yes, as Robert just pointed out. Note that most of them are actually based on
your own test suite, but most of the tests (those in the tests/run/ directory)
have an added doctest that is executed by the test runner script after
building the module.
You will also notice that the tests/errors/ directory has modules that produce
compiler errors, and the expected error messages are part of the modules
themselves.
When I wrote the test runner, my main goal was to keep the expected results in
the same file as the test code itself, so that you only have one file to edit
and look at (ok, minus .pxd and .h files). Doctests are just perfect for this.
Stefan
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
