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 _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
