[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Mark Dickinson]

Mark Dickinson added the comment:

Yay! Thanks, Benjamin.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Roundup Robot]

Roundup Robot added the comment:

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

--
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Stefan Krah]

Stefan Krah added the comment:

Larry Hastings  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. :)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Larry Hastings]

Larry Hastings added the comment:

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?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Mark Dickinson]

Mark Dickinson added the comment:

> 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?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Andreas Schwab]

Andreas Schwab added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Larry Hastings]

Larry Hastings added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[mirabilos]

mirabilos added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[mirabilos]

mirabilos added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Andreas Schwab]

Andreas Schwab added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Stefan Krah]

Stefan Krah added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Andreas Schwab]

Andreas Schwab added the comment:

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

Andreas.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[mirabilos]

mirabilos added the comment:

Andreas Schwab dixit:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Andreas Schwab]

Andreas Schwab added the comment:

Finn Thain  writes:

> until Aranym gets fixed.

Aranym *is* fixed.

Andreas.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[mirabilos]

mirabilos added the comment:

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

>

bye,
//mirabilos
-- 
 Beware of ritual lest you forget the meaning behind it.
 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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Andreas Schwab]

Andreas Schwab added the comment:

There is no excuse for using a broken emulator.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[mirabilos]

mirabilos added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Andreas Schwab]

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[mirabilos]

mirabilos added the comment:

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

Reasoning is same as in #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.)

--
nosy: +mirabilos

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Andreas Schwab]

Andreas Schwab added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Larry Hastings]

Larry Hastings added the comment:

(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.99% 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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Benjamin Peterson]

Benjamin Peterson added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Stefan Krah]

Stefan Krah added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Andreas Schwab]

Andreas Schwab added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Martin v . Löwis]

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Martin v . Löwis]

Martin v. Löwis added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Antoine Pitrou]

Antoine Pitrou added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Tim Peters]

Tim Peters added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Benjamin Peterson]

Benjamin Peterson added the comment:

I don't want to scare away contributors.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Larry Hastings]

Larry Hastings added the comment:

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.  Is 
anybody here in a hurry?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Benjamin Peterson]

Benjamin Peterson added the comment:

Well, no one has produced a reference for this phantom announcement.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Larry Hastings]

Larry Hastings added the comment:

I agree that it's a short and straightforward patch, and as stated I wouldn't 
mind accepting it.  However, I don't make a habit of going against Guido's 
rulings.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Benjamin Peterson]

Benjamin Peterson added the comment:

This is a short and straightforward patch that improves the Python experience 
for m86k users. I think it should be applied.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Andreas Schwab]

Andreas Schwab added the comment:

That's what I call hostile.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Larry Hastings]

Larry Hastings added the comment:

It sounds like this definitely won't happen for 3.4.  And if Guido has indeed 
declared "no code for unsupported platforms", it won't happen for 3.5 either.

--
versions:  -Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Mark Dickinson]

Mark Dickinson added the comment:

> I guess they will get fixed over time, or declared unsupported. :-)

Yes, probably.  I'd fully support a move to get rid of that legacy code in 
Python 3.5.  That would definitely require a python-dev discussion, though (and 
possibly a PEP): up until now the policy has been that Python just works with 
whatever floating-point format the platform's C double provides, with no 
assumptions about IEEE 754, etc.

I think we've mostly fixed the issues on mainstream platforms (e.g., Sun and 
Intel compilers on x86).  Probably the most troublesome remaining case is ARM / 
OABI, where I think we still don't have code to deal with the mixed-endian 
(more strictly, little-endian swapped words) format for C doubles.  There are 
some online environments (Python via JavaScript, etc.) that also currently use 
the legacy code.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Arfrever Frehtes Taifersar Arahesis]

Changes by Arfrever Frehtes Taifersar Arahesis :


--
nosy: +Arfrever

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Andreas Schwab]

Andreas Schwab added the comment:

I guess they will get fixed over time, or declared unsupported. :-)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Mark Dickinson]

Mark Dickinson added the comment:

> Since you say the non-short-float code is legacy this will make it also 
> possible to drop it.

That's unfortunately not true (much as I'd like it to be).  Even with this 
patch, there may still be non-gcc / x86 combinations where we potentially need 
the fallback code.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Andreas Schwab]

Andreas Schwab added the comment:

I didn't bother since this one fixes it for me (and also other python modules). 
 IMHO it's the correct way to fix it, since no other architecture except these 
two will have the problem.  Since you say the non-short-float code is legacy 
this will make it also possible to drop it.

FWIW, I don't really care which version will carry the patch, since I can apply 
it locally anyway.  But I don't want to carry it indefinitely.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Mark Dickinson]

Mark Dickinson added the comment:

Though depending on what the test failures look like, some of them may be 
indications of issues elsewhere.

Is there already an issue open for the failing tests?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Mark Dickinson]

Mark Dickinson added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Andreas Schwab]

Andreas Schwab added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Mark Dickinson]

Mark Dickinson added the comment:

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

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Larry Hastings]

Larry Hastings added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Martin v . Löwis]

Martin v. Löwis added the comment:

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.

--
nosy: +loewis

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Georg Brandl]

Georg Brandl added the comment:

> Can we move along, please?

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Antoine Pitrou]

Antoine Pitrou added the comment:

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

Can we move along, please?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Mark Lawrence]

Mark Lawrence added the comment:

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?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Georg Brandl]

Georg Brandl added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Stefan Krah]

Changes by Stefan Krah :


--
stage:  -> patch review
versions: +Python 3.5 -Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Larry Hastings]

Larry Hastings added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Mark Lawrence]

Mark Lawrence added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Georg Brandl]

Georg Brandl added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Stefan Krah]

Stefan Krah added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Mark Lawrence]

Mark Lawrence added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Georg Brandl]

Georg Brandl added the comment:

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

--
nosy: +georg.brandl

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Benjamin Peterson]

Benjamin Peterson added the comment:

Ignore Mark Lawrence.

--
nosy: +benjamin.peterson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Andreas Schwab]

Andreas Schwab added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Mark Lawrence]

Mark Lawrence added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Andreas Schwab]

Andreas Schwab added the comment:

What do you mean with code churn?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Mark Lawrence]

Mark Lawrence added the comment:

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

--
nosy: +BreamoreBoy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Andreas Schwab]

Changes by Andreas Schwab :


--
versions: +Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Andreas Schwab]

Changes by Andreas Schwab :


Removed file: http://bugs.python.org/file34387/m68k-float-prec.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Larry Hastings]

Larry Hastings added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Antoine Pitrou]

Antoine Pitrou added the comment:

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/

--
nosy: +pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Andreas Schwab]

Andreas Schwab added the comment:

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

--
Added file: http://bugs.python.org/file34412/m68k-float-prec.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Larry Hastings]

Larry Hastings added the comment:

Does Python still officially support m68k?

--
nosy: +larry

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Stefan Krah]

Stefan Krah added the comment:

Mark Dickinson  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 ...

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Andreas Schwab]

Andreas Schwab added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Mark Dickinson]

Mark Dickinson added the comment:

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?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +mark.dickinson, skrah, tim.peters

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k

[Andreas Schwab]

New submission from Andreas Schwab:

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.

--
components: Interpreter Core
files: m68k-float-prec.patch
keywords: patch
messages: 213359
nosy: schwab
priority: normal
severity: normal
status: open
title: HAVE_PY_SET_53BIT_PRECISION for m68k
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file34387/m68k-float-prec.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com