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.
But if this is not done, then the situation just becomes too unclear for
external typedefs (it second-guesses in some cases and not in others).
As for division etc. (of course, this would be good to have anyway, just
making a note): What is involved is CNumericType.rank, which should be
set to None in the case of ?-declaration. Any code depending on
comparison of this rank should not accept ?-types (give syntax error).
Grep shows that ".rank" occurs 19 times, so this shouldn't be too hard
(i.e. add a check for None and an error message at each point where the
rank is needed).
> I agree on this particular point... member descriptors is something
> that is not worth changing. Or perhaps it would make sense to change
> the whole thing? We could use the current size-agnostic handling of
> ctypedef's for ALL integral types, even the builtin ones... That would
> certainly make the Cython codebase simpler, right?
Only by a single if-test as it is now.
--
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev