On 5/29/06, Tim Peters <[EMAIL PROTECTED]> wrote: > [Thomas Wouters] > > ... > > Perhaps more people could chime in? Am I being too anal about backward > > compatibility here? > > Yes and no ;-) Backward compatibility _is_ important, but there seems > no way to know in this case whether struct's range-checking sloppiness > was accidental or deliberate.
I'm pretty sure it was deliberate. I'm more than likely the original author of this code (since the struct module was originally mine), and I know I put in things like that in a few places to cope with hex/oct constants pasted from C headers, and the general messiness that ensued because of Python's lack of an unsigned int type. This is probably a case that was missed by PEP 237. I think we should do as Thomas proposes: plan to make it an error in 2.6 (or 2.7 if there's a big outcry, which I don't expect) and accept it with a warning in 2.5. > - If it _was_ intended that range-checking be sloppy, nobody > bothered to document it. Mea culpa. In those days we didn't document a lot of things. > - Or even to write a comment in the code explaining that obscure > intent. It never occurred to me that it was obscure; we did this all over the place (in PyArg_Parse too). > - When I implemented the Q (8-byte int) format code, I added > correct range-checking in all cases, and nobody ever complained > about that. It's really only a practical concern for 32-bit values on 32-bit machines, where reasonable people can disagree over whether 0xffffffff is -1 or 4294967295. > - As noted in the comment above, we have gotten complaints about > failures of struct range-checking at other integer widths. > > OTOH, BUGGY_RANGE_CHECK existed because I was too timid to risk > making broken user code visibly broken. > > So, in all, I'm 95% sure 2.4's behavior is buggy, but 50% unsure that > we need to warn about it before repairing it. Since you (Thomas) want > warnings, and in theory it only affects the lightly-used "standard" > modes, I do lean in favor of leaving the standard modes that _are_ > broken (as above, not all are) broken in 2.5 but warning that this > will change in 2.6. I'm not sure what we gain by leaving other std modules depending on struct's brokenness broken. But I may be misinterpreting which modules you're referring to. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
