[Ronald Oussoren, hijacking the "test_struct failure on 64 bit platforms" thread]
The really annoying part of the new struct warnings is that the warning line mentions a line in struct.py instead the caller of struct.pack. That makes it hard to find the source of the warning without telling the warnings module to raise an exception for DeprecationWarnings.
The problem seems to be that Python's C API apparently gives no simple way to supply a value for warning.warn's optional `stacklevel` argument. The C-level signature is:
int PyErr_Warn(PyObject *category, char *message);
and that's what _struct.c calls. I think it would be good to add a new
int PyErr_WarnEx(PyObject *category, char *message, long stacklevel);
C API function, change PyErr_Warn to call that forcing stacklevel to 1, and change _struct.c to call PyErr_WarnEx with stacklevel=2. Then it would point at struct.pack()'s caller.
As noted in
it looks like we need a new Python C API function to make new warnings from the struct module non-useless. For example, runnning test_zipfile on Windows now yields
""" test_zipfile C:\Code\python\lib\struct.py:63: DeprecationWarning: struct integer overflow masking is deprecated return o.pack(*args) """
This is useless because the message points _into_ struct.py, not to the code calling struct.pack(). Consequently I have no idea where the offending pack() call is, and neither do you ;-)
The current PyErr_Warn() doesn't allow for passing a non-zero `stacklevel` argument to warnings.warn(), so there's little the C code in _struct.c can do to make the warning more useful.