On Wed, Jul 8, 2009 at 3:46 PM, Dag Sverre Seljebotn<[email protected]> wrote: > Robert Bradshaw wrote: >> On Jul 7, 2009, at 11:24 AM, Lisandro Dalcin wrote: >> >>> On Tue, Jul 7, 2009 at 2:30 PM, Dag Sverre >>> Seljebotn<[email protected]> wrote: >>>> I disagree, I think second-guessing is wonderful. (That is, if you >>>> want >>>> me to understand this, you must explain more -- of course, it is >>>> not a >>>> necessity that I understand this.) >>>> >>>> If the only effect is to save a few lines of C and a few cycles of >>>> CPU >>>> time for gcc, then I don't think it is worth it to complicate the >>>> language. >>>> >>> >>> It is not about saving lines of CPU cycles... It's about providing a >>> way for users to say: Hey! This extern ctypedef is EXACTLY what I >>> declared Why is Cython trying to be smart and second-guess me, I'm >>> adult enough ... >>> Moreover, what I'm proposing is 100 % backwards, and the change to the >>> languaje is rather minimal... >> >> The main point of using external typedefs is that one often doesn't >> know the exact size of the type, e.g. it's determined at c-compile >> and/or configure time. (Otherwise, one could just use int, long, or >> whatever it actually *is* and the C compiler should never complain >> after unwinding all the definitions...) I am -1 on requiring a ? when >> the type is not explicitly known. >> >> If one needs the sized to match exactly, one can "assert sizeof >> (my_int_type) == sizeof(long)." >> >> The only difference I see with the ? notation is that it would be >> explicitly unranked (whereas the standard typedef receives its >> ranking from its definition). I guess in that case certain operations >> (like arithmetic with other types) would be disallowed? I just don't >> see this as a common enough use case to need new syntax (though I'd >> be curious to hear if it does fit the bill for what someone's trying >> to do). > > (Lisandro has exited the thread it seems but I still want to finish this > because I've been wanting to do the same thing. This is another question > that's been on and off the entire spring and we should just finish it.) >
I'm back... Have to spend some time helping a coworker... > I think there is a problem here in Cython that must be fixed; it is just > too complicated. The problem is that if you need to use a type of which C > definition vary with platform (which is very common, e.g. numpy.pxd) one > currently has to say > > "Just use something, it doesn't matter in most situations; but remember to > stay away from the situations where it does matter; which ones that are we > are not even sure of ourselves." > I agree 100 % with these comments. From the very beginning I moved from SWIG/hand-C to Cython, I knew my code was broken because it was not platform-agnostic. Then I got my hands dirty to try to fix this... I've started handling the size_t/Py_ssize_t, treating then like builtin integral types. Next I added code to catch integer overflow conversions. Next Dag fixed member descriptor. Now I want to finish this for external ctypedef, in a backward way, still letting adult people do what they want, but still save them from their own bugs a possible wrong assumptions, and even from current Cython wrong assumptions... > This is hardly satisfying, and SOME kind of solution is needed here. If > only to prevent subtle bugs from mixing types from numpy.pxd with other > types in arithmetic! > Indeed. > I think the following is a solution. It might not be the only one, but it > is the only one presented so far: > > 1) Introduce ? notation, and make rank unknown => disable some arithmetic > 2) If ? is not used, require and enforce exact match. > > This has the advantage that it is a) extremely easy to explain, b) guards > against any kinds of errors (and if one needs type-combining arithmetic, > just cast). > Moreover, if we take (2) we just make Cython a not so useful tool for wrapping external libs. It would be impossible to write portable Cython code, end users will have to fix type definitions by hand (of developers start wasting time with distutils based configure-like support). Any external lib (MPI in my case) defining a integral type for address-sized integers will be a nightmare to handle. Also I will have problems in petsc4py. You can build core PETSc in different ways, with 32/64 bit integers (PetscInt type), with single/double presicion reals (PetscReal type)... So the actual sizeof of PetscInt/PetscReal depends on how you built core PETSc... In short, if we do (2), we will break on of the (at least in my POV) most important use cases of Cython, i.e. wrapping C/C++ stuff. -- Lisandro Dalcín --------------- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
