[Pyrex] Does __Pyx_ImportType need to check struct sizes? (Cython-relevant, too)
Robert Kern
robert.kern at gmail.com
Tue May 26 17:28:25 CEST 2009
On 2009-05-24 07:07, Greg Ewing wrote:
> Robert Kern wrote:
>> What is the reasoning behind having __Pyx_ImportType check that the imported
>> type's size at runtime matches exactly the type's size at compile time?
>
> It's meant to provide some degree of safeguard against
> changing the definition of a type and failing to
> recompile all the Pyrex modules that import it.
>
> I know it's not a perfect check, but I thought it
> would be better than nothing.
Has it ever helped you? Or is this just a hypothetical? I've never needed it
when writing raw extension modules.
> Remember that it may
> not only be you that's affected by the change, but
> someone else importing your type into their Pyrex
> module. Without any check, they'll just get a
> segfault with no clue as to what went wrong.
Unfortunately, the current message is less than ideal for this purpose, too.
Perhaps a note that recompiling might solve the problem would help those who are
not developers writing Pyrex code, just users of those packages.
> Also note that adding fields to the end is only
> safe in the absence of subclassing.
Yup. That is the case here. In my ten years of using numpy and its predecessor
Numeric, I have never seen anyone subclass this type or even a potential use
case for doing so.
> I might be persuaded to drop the check, but only
> if everyone promises not to complain if their
> Pyrex modules fail inexplicably. :-)
<shrug> *I* won't. I can't speak for anyone else.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
More information about the Pyrex
mailing list