> I don't think fixing bugs on a specific architecture counts as a new feature.

It's not really a bugfix, though.  Python 3.4 *should* (I'm not in a position to check, but Andreas may be) be behaving as designed on m68k: the configure script will correctly determine that there's a potential issue with double rounding, and since it doesn't currently know of any way to control the FPU precision setting on m68k, it'll set the environment variables up so that the legacy floating-point repr code is used.  The built Python should function as normal, expect that sys.float_repr_style will be 'legacy' instead of 'short', and we won't get the (primarily cosmetic) benefits of the short float repr.

This patch then changes the part where Python doesn't know how to change the precision, allowing it to use David Gay's short float repr code instead of the legacy code.  So I see it as an enhancement rather than a bugfix.

And this would actually be a somewhat significant behaviour change: on m68k with Python 3.4.0, we'd see:

>>> 1.1
1.1000000000000001

and (if this patch went into the 3.4 branch), on Python 3.4.1 we'd see instead:

>>> 1.1
1.1

The behaviour of string formatting and the round function would also change in edge cases.

There's an argument that the number of users affected by this change is likely to be tiny, so changing this in 3.4.1 is unlikely to break people's code.  But the tininess of the userbase is equally the basis of an argument that the change isn't at all urgent, and those affected can wait for Python 3.5 or patch their copy of Python; I don't see a really good reason to break the policy about new features on bugfix branches for this particular issue.

Given all that, I don't think it would be appropriate to include the change in Python 3.4.1.  I'd personally like to see it go into Python 3.5, but that's dependent on the outcome of the "we don't accept patches for unsupported platforms" discussion (which is orthogonal to the 'is this an enhancement or a bugfix' discussion).