Re: Does __Pyx_ImportType need to check struct sizes? (Cython-relevant, too)

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