<br><div><span class="gmail_quote">On 5/29/06, <b class="gmail_sendername">Fredrik Lundh</b> <<a href="mailto:fredrik@pythonware.com">fredrik@pythonware.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Thomas Wouters wrote:<br><br>> I know which 'it' I meant: the same 'it' as struct already accepts in<br>> Python 2.4 and before. Yes, it's inconsistent between formatcodes and<br>> valuetypes -- fixing that the whole point of the change -- but that's
<br>> how you define 'compatibility'; struct, by default, should do what it<br>> did for Python 2.4, for all operating modes.<br><br>that's how you define compatibility for bug fix releases in Python. 2.5<br>is not
2.4.4.</blockquote><div><br>Correct, and it is also not 2.6. Breaking perfectly working (and more to the point, non-complaining) code, even if it is for a good reason, is bad. It means, for instance, that I can not upgrade Python on any of the servers I manage, where Python gets used by clients. This is not a hypothetical problem, I've had it happen too often (although fortunately not often with Python, because of the sane policy on backward compatibility.)
<br><br>If 2.5 warns and does the old thing, the upgrade path is easy and defendable. This is also why there are future statements -- I distinctly recall making the same argument back then :-) The cost of continuing the misfeatures in struct for one release does not weigh up to the cost of breaking compatibility unwarned.
<br></div></div><br>-- <br>Thomas Wouters <<a href="mailto:thomas@python.org">thomas@python.org</a>><br><br>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!