Lisandro wrote: > 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.
I think you mistunderstood me... I meant (1) and (2) in combination. Trying again: 1) We introduce "?" 2) If you do not know the exact type, you HAVE to use ?. Not using ? implies you know the exact type. Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
