[Numpy-discussion] Toward a numpy build with warning: handling unused variable
Sun Aug 3 20:39:08 CDT 2008
On Sun, 2008-08-03 at 19:32 -0500, Charles R Harris wrote:
> There is self and args, filter them out. If the arguments have other
> names, rename them.
That's much more error prone. You would need a list of such arguments,
and more importantly, it means you cannot enable warning by default
(because you cannot expect the casual user to filter them out).
And if you filter them out, you won't see them, meaning you hide them
anyway. So I don't really see the point.
> > If the warnings are too
> > numerous, filter them.
> If you filter them, what's the point of keeping them ?
> Because the compiler's inadequate determination of errors is driving
> the coding.
I don't understand what you mean here ? The problem I see is the
following: currently, there are so many warnings that we don't enable
them, and I would guess nobody currently enable them.
> That seems wrong way around. Maybe these variables can be notated
> somehow, i.e, __unused__(arg), which would at least document intent.
Which is what I have been arguing all along :) If you look at the link I
posted before, it suggests a UNUSED macro which uses gcc attribute when
build with gcc, and do nothing otherwise:
#define NPY_UNUSED(x) NPY_UNUSED__ ## x __attribute__((unused))
#define NPY_UNUSED(x) x
This makes it hard to get it wrong:
- you can't use the variable by accident later: you will get a
compilation error thanks to the mangling
- you don't have meaningless warnings, meaning you see the real ones.
- if you don't use gcc, it is exactly as before.
I realize I may have not been not really clear: I am not suggesting to
remove any warning about unused variable, just the ones which we cannot
do anything about because they are in the argument list and we know for
sure we will not use them. That include python C functions not used as a
method (dummy/unused, e.g. the first argument), ufunc which do not use
their func argument, etc...
More information about the Numpy-discussion