Dag Sverre Seljebotn wrote: > Lisandro Dalcin wrote: >> On Tue, Jul 7, 2009 at 2:30 PM, Dag Sverre >> Seljebotn<[email protected]> wrote: >>> Lisandro Dalcin wrote: >>>> On Tue, Jul 7, 2009 at 10:47 AM, Dag Sverre >>>> Seljebotn<[email protected]> wrote: >>>>> Or that #333-like behaviour will *only* be done if you use a "?"? If so, >>>>> for what gain? -- some fewer lines of C code? Why does it hurt to >>>>> "second-guess the user", as you put it in the OP? >>>>> >>>> Because of your fist question and my previous comment. Second-guessing >>>> will be a bad thing... >>> 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 ... > > *If* Cython can successfully generate generic code that works in all > cases, then I don't see a need for an option to not do so, even if it > makes me look more macho :-) > >> Moreover, what I'm proposing is 100 % backwards, and the change to the >> languaje is rather minimal... > > What worries me is documenting and explaining the various modes of > operation; particularily because the current external typedef mode is so > hard to explain (people are already relying on the second-guessing that > is there). > >> Dag, are you 100 % confident that treating all extern ctypedef >> integrals as unknown-size will not break something or let >> overflow/truncation errors pass silently? > > No, but such issues must be fixed for the ?-syntax too... > >>> I do think this could be good to have if we inserted code at module init >>> time to raise exceptions if sizeof(foo) != sizeof(bar) for all external >>> typedefs, so that exactness is *enforced* in those situations. (That may >>> break some backwards compatability but I think it is OK myself.) If that >>> approach is also taken, at the same time, and this isn't done until >>> 0.12, then +1. >>> >> Sorry, I'm confused here... In which situation do you want to *enfoce* >> sizeof(foo) == sizeof(bar) ? Can you provide some code snippet? Do you >> mean that if I write this in mpi4py >> >> cdef extern from "mpi.h": >> ctypedef signed long MPI_Aint >> >> then mpi4py will fail to import on Win64 (MPI_Aint is a address-sized >> signed integral)? > > What I mean is that in that in modules importing this code, the module > initialization function gets something very similar to this piece > inserted (probably PyErr_Format and a constant message instead though): > > if (sizeof(signed long) != sizeof(MPI_Aint) || (MPI_Aint)-1 != -1 > || (MPI_Aint)1 / 2 != 0) { > PyErr_String(PyExc_RuntimeError, "MPI_Aint is not 'signed int' on > this system (consider declaring it as 'cdef signed int? MPI_Aint' if > the size is not known in the Cython code)"); > } > > This will make sure that backwards compatability is *broken* (in a > friendly way) in cases where people are currently relying on > second-guessing for external types (like with buffers). > > Most cases are not broken though. > > If this is done, then the feature is easy to understand and document and > I'm definitely +1.
Just a note: I'm actually really, really happy if this happens, I'm just trying to refine it a bit :-) If numpy.pxd said ctypedef int? int16_t I would get a lot less questions about how it works... -- Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
