> Greg Ewing <greg@cosc.canterbury.ac.nz> writes: > > > > It means that your code *will* break in Python 2.4, unless you take > > > corrective action (which you cannot take at the moment). > > > > Pardon me, but... wouldn't it have been better to defer > > introducing these warnings until there *is* something > > that can be done about them? > > That might be the case. At the time the warning was added, there was > consensus that it is be easy to do something about each of them. That is true. To be fair, the warning is simply saying "this literal is an int today - later it will be a long". It is not supplying any context for this warning - ie, it is not saying "your C extensions using 'l' format may break" - it is left to us to deduce such impacts. > Today, I would rather hope that somebody contributes a patch to add > the requested features instead of contributing a patch to disable the > warning. Except, on the flip-side, let's say I am *happy* for such contants to become longs. I really don't want to see the warning for every hex literal once I understand the impact. So, maybe we simply need finer-grained warnings - such as in PyArg_ParseTuple, and any other places where the impact will actually be felt. Mark.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4