> > I was just bit by an older PyArg_ParseTuple format string behavior > > change: these days (since 2.1?) "h" barfs when you feed it an > > unsigned short value (even if it's within 16 bits). So ok, I updated > > my code to use "H" instead, only to find out hours later that "H" > > didn't exist yet in 1.5.2. I really need to be compatible with both > > so I'll have to work around it :-( > > > > Was this change really neccesary? > > Yes, the old behavior was indefensible. > > Jack complained about it too, but in the end agreed he'd update his > code. Well, "agreed" is a rather gentle description here. "Jack was dragged to his machine kicking and screaming where he spent months (literally) finding these nasty changes, and he still mutters and whimpers occasionally". I think that about 99% of the uses of the "h" format specifier were in code that I felt responsible for, and each of these had to be carefully inspected. I still find them, occasionally (there was another one last month). And don't even _dream_ of "fixing" the "l" format in the same way:-) -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm
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