[Pyrex] Another lvalue cast bites the dust

[Lenard Lindstrom]

I wondered why Pyrex kept non PyObject * variables around. I suppose 
all static global and local variables can be PyObject * at the C 
level. But anything imported or exported has to be treated properly. 
The Python api function PyEval_EvalCode takes a PyCodeObject *  
argument, for instance. So non (PyObject *) python object lvalues 
need to be handled anyways.

I think there are only a few places where lvalue casts can appear. So 
I will check them and make any necessary fixes.

Lenard Lindstrom
<len-l at telus.net>

On 19 Oct 2005 at 12:33, Greg Ewing wrote:

> Thinking about the ArrayType return value problem,
> I'm beginning to wonder whether it would be better
> to have Pyrex declare *all* Python-valued variables,
> parameters and return values as PyObject *, and cast
> to an extension type only when accessing an attribute.
> 
> This would be more in keeping with the conventions
> used in other Python extension code, and may lead to
> fewer problems of the above type. Also, I suspect it
> would eliminate most of the situations where lvalue
> casting is currently used.
> 
> I actually had Pyrex doing things that way at one
> time, and I changed it because the extra casting
> being done was making the generated code very verbose,
> and hard to verify for correctness due to bypassing
> almost all of C's type checking.
> 
> While you're experimenting, you might like to consider
> trying such a scheme and seeing if it simplifies anything.
> 
> Greg
>