On 5/29/06, Fredrik Lundh <fredrik@pythonware.com> wrote:
Thomas Wouters wrote:

> I know which 'it' I meant: the same 'it' as struct already accepts in
> Python 2.4 and before. Yes, it's inconsistent between formatcodes and
> valuetypes -- fixing that the whole point of the change -- but that's
> how you define 'compatibility'; struct, by default, should do what it
> did for Python 2.4, for all operating modes.

that's how you define compatibility for bug fix releases in Python.  2.5
is not 2.4.4.

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.)

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.

--
Thomas Wouters <thomas@python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!