Stefan Behnel wrote:
> Greg Ewing wrote:
>
>>There's no run-time
>>distinction between a builtin class, an extension class
>>implemented with Pyrex, or an extension class created some
>>other way.
>
> I didn't mean at runtime. The compiler knows how to distinguish them.
Well, there's no compile-time distinction either, really.
They're all the same thing. Treating a type differently
depending on whether it was implemented using a Pyrex
extension class would be bizarre and confusing.
> allowed_type = ExtType
> print isinstance(obj, allowed_type) # Python semantics
That's not the only possibility. There's also
f = isinstance
if f(ob, MyExtensionClass):
...
You're testing against an explicitly-named class -- but
using the Python version of isinstance rather than the
Pyrex one.
> Besides, the actual difference of allowing or disallowing a type override
> through ".__class__" is so tiny that almost no user will actually notice,
Possibly you're right. However, I do have a guideline
of my own concerning Python compatibility: if a function
has the same name as a Python function, then you can
rely on it to have the same semantics.
There's another consideration as well: What do you do
if you really *do* want exactly the same semantics as
the Python isinstance()? There would have to be another
function for that, which *is* exactly the same as
isinstance(), but has a different name.
That situation could be considered somewhat farcical.
> 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.
Hmmm. I don't really want to include a lot of tests
that are more or less duplicates of the existing ones.
If you have any new, Cython-specific tests that you
think ought to work in Pyrex as well, I'd be happy to
run those.
But I don't see how much will be gained by just including
all the Cython tests as-is. I'm not going to be changing
my own test setup, so you're not going to be able to share
any new tests that I add without converting them to your
format. And new tests for Cython-specific features probably
won't apply to Pyrex anyway.
If you find a bug and come up with a new test to guard
it against regression, I think I would actually rather
convert it to my test format and make it one of my tests.
So I would be happy for you to bring any such tests to
my attention.
> 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
There is one advantage to keeping them separate -- after
I've fixed everything so that the expected and actual results
are near enough to being in sync, I can run a script that
automatically updates the expected results from the last
actual results. That would be hard to do if the expected
results were embedded in the test files.
This is probably more important for the compilation tests,
where the "expected result" is large and can change in ways
that are ignorable. But having built the framework to cope
with that, it was easiest to just use it for everything.
--
Greg
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
