Repository navigation
Avoid DeprecationWarning for _pack_ without _layout_ when there are not bit-fields? #133800
Description
Bug report
Bug description:
New Python versions give a DeprecationWarning for struct definitions that use _pack_ = True but do not specify the _layout_.
In a sense a new feature, but as I believe this is only relevant for bit-fields: wouldn't it make sense to allow leaving _layout_ unspecified when the struct contains no bitfields?
(I suppose that means giving it some default, such as the system native layout.)
The context is just seeing this in NumPy where bit-fields are not used so I was wondering: numpy/numpy#28926.
Adding the _layout_ isn't a problem of course, but if the no-bitfield case is common (not sure) it may be nice to not be forced to "decide" on an irrelevant _layout_ (or act up on the DeprecationWarning)?
Another question that comes to mind is that _layout_ = "native" or so seems potentially useful.
CPython versions tested on:
3.14
Operating systems tested on:
Other
Activity
picnixz commentedon May 10, 2025
cc @encukou
encukou commentedon May 12, 2025
Well, the layout will be different wherever MSVC and GCC disagree.
AFAIK, that's currently only the case with bitfields, but I haven't proven that, and can't guarantee it for any future features.
We cannot add
_layout_ = "native"because_pack_not implemented for the GCC layout. With_layout_ = "native"; _pack_ = 1, you'd get an error on *nix.Historically, setting
_pack_has always implicitly switched to the MSVC layout. The attribute corresponds to MSVC's#pragma pack, not to some “platform-specific tight packing” that some readers might expect.IMO, it's in NumPy's interest to make this explicit -- by setting
_layout_ = "ms".If the deprecation is a problem, I'd be OK with removing the warning altogether, and strenghtening
_pack_'s documentation instead.(Those are just my current opinions -- feedback welcome!)
seberg commentedon May 12, 2025
I hope it was clear, I don't care too much about adding
_layout_ = "ms"to NumPy, it's just a few tests. NumPy does pack, so tests that check that we pack the same and a few tests that you can read NumPy data via ctypes.Some user may use ctypes and be confused like me (why add
_layout_ = "ms"when your code clearly works on all platforms?!). But I doubt it's common, so I really won't sweat it.GCC also has
__attribute__((packed))(also for the full struct) for structs signaling that any variable is 1-byte aligned.So
_pack_/_aligned_is modeled after the MSVC pragmas, but I don't think it is conceptually specific to a toolchain (for byte-sized variables).No need to proof anything. If
_layout_is unspecified, any possible future feature will just raise an error.encukou commentedon May 17, 2025
Well, here's the problem: the implementer of any future feature will need to remember to check whether it results in the same layout between GCC & MSVC.
I'd be OK with entirely removing the warning (and eventual hard error) for
_pack_& no_layout_. But IMO, limiting it to just bitfields would become a maintenance burden.cc @BCSharp -- this thread might be interesting for you.