[Cython] broken array declarators when size is an expression
Dag Sverre Seljebotn
dagss at student.matnat.uio.no
Tue Nov 18 14:39:06 CET 2008
Robert Bradshaw wrote:
> On Nov 15, 2008, at 12:14 AM, Stefan Behnel wrote:
>
>
>> Hi,
>>
>> Lisandro Dalcin wrote:
>>
>>> changeset: 1333:34aca76e1b9d
>>> summary: array size must be set as int, not numeric string
>>>
>>> broke mpi4py and petsc4py, where I use stack-allocated arrays where
>>> the size comes from an (external) enumeration, for example:
>>>
>>> cdef char name[MPI_MAX_OBJECT_NAME+1]
>>>
>> Sorry for that. The problem is that we don't currently have a way
>> to say "give
>> me the compile-time result for this subtree, but don't complain if
>> it's a
>> runtime value". I already needed that in a couple of places when
>> working on
>> Cython, as it can lead to different code when you know the result
>> of an
>> expression. I just never got around to implement this.
>>
>> I think it's wrong that compile_time_value() raises a compiler
>> error. It
>> should rather return the result with a hint if it was determined
>> completely or
>> if part of it is runtime-determined. Then the caller can decide
>> what to do
>> with this information.
>>
>
> This has annoyed me too. http://trac.cython.org/cython_trac/ticket/119
>
>
Idea: I was thinking of perhaps a transform that ran through the tree
and replaced anything that is a compile-time expression with its literal
result, i.e.
DEF a = 4
print a
would be turned into
print 4
by this transform directly (just by calling compile_time_value and
putting it back into IntNodes and StringNodes, really). So code after
that transform (which would be run right after parsing) would not call
compile_time_value at all -- if it is known compile-time, a literal
exprnode is there (and treated the same way as if a literal was coded in
by the user), otherwise it is only known runtime. Seems simpler than
extending the compile_time_value protocol with information about
"runtime-determined" etc.
Unfortunately I don't have time to do it.
Dag Sverre
More information about the Cython-dev
mailing list