m68k has the same problem as x86 with excess floating point precision. The attached patch implements the necessary support for HAVE_PY_SET_53BIT_PRECISION.

Technically I guess this counts as a new feature. It would be painful to have to wait for 3.5, though. I wonder whether we can sneak this in after 3.4 is released?

Is the __mc68000__ #define specific to gcc?

I don't know of any other compiler on m68k.

Mark Dickinson <report@bugs.python.org> wrote:

I wonder whether we can sneak this in after 3.4 is released?

+1. m68k affects a relatively small group of people, and Andreas Schwab is
the gcc m68k port maintainer, so ...

Does Python still officially support m68k?

I have modified the patch to include a configure check to set HAVE_GCC_ASM_FOR_MC68881 and use that instead of __mc68000__.

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

Does Python still officially support m68k?

Certainly not. We haven't had any 68k buildbot in ages (not sure we ever had any, actually).

Andreas, have you signed a contributor's agreement? You can do it online at http://www.python.org/psf/contrib/contrib-form/

I'm happy to accept the change for 3.4.1, but I'm not going to cherry-pick a fix for an unsupported platform after rc3.

It strikes me as strange that we'd allow code churn for an unsupported platform, can someone explain the rationale behind this please.

What do you mean with code churn?

Code churn is defined as lines added, modified or deleted to a file from one version to another.

That's a very broad definition, I didn't know that python is such a hostile environment.

Ignore Mark Lawrence.

@mark, I don't understand why you ask this question after several positive responses of Python committers (Mark, Stefan, Larry).

@andreas, as far as I recall, we have always welcomed patches for officially unsupported platforms, certainly as long as they only introduce special code for that platform, as is the case here.

I love you as well Benjamin :)

To be serious I think we're talking at cross purposes. I'm not against this patch. Code churn often gets mentioned here as a reason for not doing what is proposed. Changing code for an unsupported platform just struck me as odd. So if somebody explains that we're doing it for the very good reasons x, y and z I'll be perfectly happy.

So far there are only very few m68k patches. Additionally, the patches are well researched and sometimes highlight ANSI C violations.

The submitters of the patches are highly competent and apparently take testing seriously. I see no reason to reject the patches.

With respect, Mark, I think you should leave these considerations to the committers.

Great, you ask a simple, straight forward question and get told to go away. I'll therefore leave everything to the committers, including the roughly 4500 open issues and the other 40 languishing.

Since 3.4 and 3.5 are different code bases, I assume you'd be willing to check this in for both. Assuming that's the case, please tick the 3.5 version too.

Mark, I already gave a reason, which was apparently not good enough for you. Nobody told you to go away from the tracker, but it's not constructive to ask for reasons why a particular patch is accepted or rejected, by the release manager no less, if you're not the original author. (Except if you want to discuss policy, in which case the tracker is the wrong place to do it.)

I've asked a simple question and I've *NOT* had an answer. Antoine's response to Larry's question "Does Python still officially support m68k?" is certainly pertinent "Certainly not. We haven't had any 68k buildbot in ages (not sure we ever had any, actually)." The more I see here, the more laughable I think the situation is. Core devs have time to spend on an issue for an unsuppoorted platform, but don't have the time to support the 4500 issues that are presumably aimed at supported platforms. What gives?

I've asked a simple question and I've *NOT* had an answer.

Can we move along, please?

Can we move along, please?

Indeed. Further discussion, if felt to be really necessary, should take place on python-dev.

BreamoreBoy: Support for this patch comes from several properties of the patch and the way it is stated that make it easy to like it. It is well-researched, well-presented, and clearly can't have negative impact on the systems that *are* supported. This is different from the other thousands of issues which are much more difficult to rule on.

There is, of course, the standing ruling from Guido that we shouldn't let new support for minority platforms in, and phase out any such existing support that is already in the code base. By that policy, Andreas would have to support his own fork of Python.

Martin: I hadn't realized there was such a rule from Guido. Can you cite where he said that?

Obviously I didn't mind accepting this patch, as it looks like it would have roughly zero maintenance cost for anyone who doesn't care about 68k. But if Guido has said "we don't accept patches for unsupported platforms", I may have to reverse my decision.

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

It's not just cosmetic, it's breaking the testsuite back and forth.

It's not just cosmetic, it's breaking the testsuite back and forth.

Sure; those are really bugs in the tests, though: no test should be blindly assuming that the short float repr is in use. It sounds as though we're missing some skip decorators.

In the absence of Guido here, I'll channel him ;-) "The problem" with oddball platforms has been that some require major changes in many parts of the interpreter, and then all the added cruft complicates life for every maintainer, while few people benefit and the oddball platform typically has only one maintainer who vanishes for long stretches.

Guido would not object to this small, simple, well-motivated and isolated patch. At least he wouldn't object on the basis of "it's an unsupported platform".

I don't object either ;-)

That's why I haven't said firmly yes or no yet. I expect to see Guido
in just over two weeks, and if nothing turns up by then I'll ask him
in person.

It's a minor patch for a niche platform. What exactly is the point of
asking Guido in person? At worse, shoot him an e-mail. I would expect
the answer to be "I don't care".

It seems it wasn't actually a formal ruling (although I took it for that); see for yourself - or better, ask Guido what he thinks about this topic today:

https://mail.python.org/pipermail/python-3000/2007-August/009692.html
https://mail.python.org/pipermail/python-dev/2009-January/085064.html

There might be more postings on the topic which I can't find now.

What triggered my interpretation might have been this conversation:

https://mail.python.org/pipermail/python-dev/2002-May/023998.html
https://mail.python.org/pipermail/python-dev/2002-May/024006.html

We are actually talking about Linux here, I assume everyone knows what that is :-)

Also the patch is 2 files changed, 32+ (if you ignore the autoconf generated files), which is quite a bit smaller than the final version of the atheos patch (which is 19 files changed, 544+, 15-, also generated files ignored).

Benjamin Peterson <report@bugs.python.org> wrote:

I don't want to scare away contributors.

I think this is a very important point. Initially I was skeptical about m68k,
too (msg182388), but I've completely changed my opinion due to the nature
of the patches.

So far, the m68k issues were about C-standard compliance and timing assumptions
in tests.

This one is a small patch that won't affect anything else.

My experience with exotic Linux ports (Debian SPARC, etc.) is that the Python
test suite works rather well out of the box. So I don't expect to have a flood
of posixmodule.c patches or similar (perhaps Andreas can confirm that).

On Mon, Mar 24, 2014, at 14:56, Martin v. Löwis wrote:

Martin v. Löwis added the comment:

What triggered my interpretation might have been this conversation:

https://mail.python.org/pipermail/python-dev/2002-May/023998.html
https://mail.python.org/pipermail/python-dev/2002-May/024006.html

In this case, though, the patch gets accepted:
https://mail.python.org/pipermail/python-dev/2002-May/024036.html

(And hooray for that, given the meteoric rise of AtheOS. :| )

I'm going to go way out on a limb and say that Guido hasn't made a pronouncement here. Also, the discussions cited by Martin are about entire new platforms (AtheOS, Haiku), whereas what we're talking about here is an additional architecture for an existing platform (m68k on linux).

So I'm going to use my best judgement. I'm willing to accept the patch for 3.5, provided that:

• it's understood that m68k is not an officially supported
  platform, and

• this is sufficient, we won't need loads of other m68k support
  patches. (As the saying goes, this patch should not be a
  "foot in the door".)

I do have two questions:

• With this patch applied, how much of the test suite passes?

• Is there a way that the configure check could be skipped on non-m68k
  platforms? Because 99.999999% of the time, that check is irrelevant,
  and configure is already slow enough.

  Could you possibly just drop the GCC check? Do you genuinely support
  m68k on linux using revisions of GCC that don't support inline
  assembly?

Finally, Mark Dickinson is right: since this patch changes behavior in an incompatible way, it's not permissible to check it in for 3.4. Sorry.

342 tests OK.
2 tests altered the execution environment:
test_site test_warnings
33 tests skipped:
test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp
test_codecmaps_kr test_codecmaps_tw test_curses test_dbm_gnu
test_dbm_ndbm test_devpoll test_idle test_ioctl test_kqueue
test_msilib test_ossaudiodev test_pep277 test_readline
test_smtpnet test_socketserver test_sqlite test_ssl test_startfile
test_tcl test_timeout test_tk test_ttk_guionly test_ttk_textonly
test_unicode_file test_urllib2net test_urllibnet test_winreg
test_winsound test_xmlrpc_net test_zipfile64

Veto on m68k-float-prec.patch for Linux/m68k for now.

Reasoning is same as in bpo-18062 (thanks skrah for linking it):

Enabling this *will* break Python on Linux/m68k on the most
widespread emulator in all released versions of that emulator
(ARAnyM) because the emulator does not handle reducing precision
correctly.

The same applies to all other m68k OSes running in ARAnyM
(FreeMiNT comes to mind, I believe it could run Python).

I think this could be applied when a released version of
ARAnyM that works correctly even with this patch is in,
say, Debian oldstable and RHEL, or something like that.

The problem here is that this *will* create a run-time issue.
(I had prepared a similar patch, but decided to fix the old
dtoa code instead due to the emulator issue.)

Enabling this *will* break Python on Linux/m68k

??? It will not of course, it will *fix* it. You have no idea what you are talking about.

Andreas Schwab dixit:

Andreas Schwab added the comment:

> Enabling this *will* break Python on Linux/m68k

??? It will not of course, it will *fix* it. You have no idea what you are talking about.

No: it will break Debian/m68k which heavily uses Python, because:

• on real metal m68k, the asm function will be tested and work,
  so it will be used, including the new dtoa code
• the binaries with that will be uploaded to the archive
• now, on emulated m68k (ARAnyM), those binaries will use the
  new dtoa code instrad of the old one, but the asm instructions
  to change FPU precision will SILENTLY FAIL, which will lead
  to incorrect results

bye,
//mirabilos

<igli> exceptions: a truly awful implementation of quite a nice idea.
<igli> just about the worst way you could do something like that, afaic.
<igli> it's like anti-design. <mirabilos> that too… may I quote you on that?
<igli> sure, tho i doubt anyone will listen ;)

There is no excuse for using a broken emulator.

Andreas Schwab dixit:

There is no excuse for using a broken emulator.

Sure, if nobody releases a fixed version… and even then,
there’s got to be a grace period.

I say that if you break ARAnyM you kill off Debian/m68k
on ARAnyM (and I’ll have to shut down my buildd, too).

<http://bugs.python.org/issue20904\>

bye,
//mirabilos

<diogenese> Beware of ritual lest you forget the meaning behind it.
<igli> yeah but it means if you really care about something, don't
ritualise it, or you will lose it. don't fetishise it, don't
obsess. or you'll forget why you love it in the first place.

Finn Thain <fthain@telegraphics.com.au> writes:

until Aranym gets fixed.

Aranym *is* fixed.

Andreas.

Andreas Schwab dixit:

Finn Thain <fthain@telegraphics.com.au> writes:

>Sorry, what? You seek to veto an upstream Python bug fix because it will
>lead to correct binaries that a certain emulator can't handle? That

Yes, because of the value ARAnyM has for Linux/m68k development
and especially testing – for example, considering that there are
no porterboxen, we can, currently, just tell people needing one
to install a VM themselves, and even provide images from which
to start.

>Furthermore, Andreas' bug fix was to be merged for python 3.5. Debian is
>not obliged to use that version with that patch up until Aranym gets

Debian is consistent across architectures. (Well, mostly.) This
patch changes a known-good but less optimal behaviour (using the
old dtoa routines) by behaviour that matches the other architectures
even better but only iff the FPU (FPU emulation) supports changing
precision. Which it didn’t last time I looked.

>fixed.

Aranym *is* fixed.

What *precise* version of ARAnyM is the first to have been released
with a fix for this issue?

I never got any response to my message to upstream in which I asked
for a release: <Pine.BSM.4.64L.1403211905340.7386@herc.mirbsd.org>
(No response *at all*, mind you. Not even an ACK or “no”.)

Once we do have a fixed version, we can communicate that around.
(Note that “have” includes having e.g. backports to stable and
several old *buntu versions at least.)

bye,
//mirabilos

<igli> exceptions: a truly awful implementation of quite a nice idea.
<igli> just about the worst way you could do something like that, afaic.
<igli> it's like anti-design. <mirabilos> that too… may I quote you on that?
<igli> sure, tho i doubt anyone will listen ;)

The fixed version is here: git://git.code.sf.net/p/aranym/code

Andreas.

If the asm instructions silently fail, I'd say add a test to ./configure
that detects the broken versions of the emulator in question.

Or don't bother and tell people to use the proper version of
the emulator.

There is nothing that fails. The emulator has always correctly implemented the insn.

Stefan Krah dixit:

If the asm instructions silently fail, I'd say add a test to ./configure
that detects the broken versions of the emulator in question.

No, the problem is at runtime: Debian is a binary distro, and thus,
packages can get built and/or used on either ARAnyM, Amiga, Atari,
Macintosh, and in theory VME machines, and maybe Q40/Q60, and maybe
UAE (Amiga emulator).

bye,
//mirabilos

<igli> exceptions: a truly awful implementation of quite a nice idea.
<igli> just about the worst way you could do something like that, afaic.
<igli> it's like anti-design. <mirabilos> that too… may I quote you on that?
<igli> sure, tho i doubt anyone will listen ;)

Andreas Schwab dixit:

The fixed version is here: git://git.code.sf.net/p/aranym/code

That’s a source repository. I was asking for released tarballs
that have been packaged.

But clearly I have been outvoted by the m68k porters. So please
feel free to go ahead and break Debian/m68k on released ARAnyM.
I retract my veto.

bye,
//mirabilos

<igli> exceptions: a truly awful implementation of quite a nice idea.
<igli> just about the worst way you could do something like that, afaic.
<igli> it's like anti-design. <mirabilos> that too… may I quote you on that?
<igli> sure, tho i doubt anyone will listen ;)

I retract my veto.

You don't have a "veto". Only Guido has that.

Anyhow you have yet to reply to Mr. Schwab's assertion:

The emulator has always correctly implemented the insn.

If that's true, then I don't understand what this whole argument is about.

The only problem is that under some conditions involving denormalized numbers the result may lose a bit of precision. But that is mostly irrelevant for this issue, at least it wouldn't make it worse than it is now.

under some conditions involving denormalized numbers the result may lose a bit of precision

That sounds like a non-issue for this application: the dtoa.c computations are careful to avoid subnormals in intermediate computations.

If mirabilos has withdrawn his objection, is there anything blocking applying this for 3.5?

Okay, I say let's check this in. If mirabilos can cite problems it causes we can revert it.

Andreas, is there someone who would normally check this in for you, or should I do it?

Larry Hastings <report@bugs.python.org> wrote:

Andreas, is there someone who would normally check this in for you, or should I do it?

Traditionally Mark commits the floating point stuff. :)

New changeset c2f6551c9eaf by Benjamin Peterson in branch 'default':
support setting fpu precision on m68k (closes bpo-20904)
http://hg.python.org/cpython/rev/c2f6551c9eaf

Yay! Thanks, Benjamin.