Issue 20904: HAVE_PY_SET_53BIT_PRECISION for m68k (original) (raw)
Created on 2014-03-13 07:54 by schwab, last changed 2022-04-11 14:57 by admin. This issue is now closed.
Messages (68)
Author: Andreas Schwab (schwab) *
Date: 2014-03-13 07:54
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.
Author: Mark Dickinson (mark.dickinson) * 
Date: 2014-03-13 17:27
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?
Author: Andreas Schwab (schwab) *
Date: 2014-03-13 17:58
I don't know of any other compiler on m68k.
Author: Stefan Krah (skrah) *
Date: 2014-03-13 18:16
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 ...
Author: Larry Hastings (larry) *
Date: 2014-03-13 18:19
Does Python still officially support m68k?
Author: Andreas Schwab (schwab) *
Date: 2014-03-14 06:43
I have modified the patch to include a configure check to set HAVE_GCC_ASM_FOR_MC68881 and use that instead of mc68000.
Author: Antoine Pitrou (pitrou) *
Date: 2014-03-14 10:13
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/
Author: Larry Hastings (larry) *
Date: 2014-03-14 12:54
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.
Author: Mark Lawrence (BreamoreBoy) *
Date: 2014-03-23 16:53
It strikes me as strange that we'd allow code churn for an unsupported platform, can someone explain the rationale behind this please.
Author: Andreas Schwab (schwab) *
Date: 2014-03-23 16:57
What do you mean with code churn?
Author: Mark Lawrence (BreamoreBoy) *
Date: 2014-03-23 17:00
Code churn is defined as lines added, modified or deleted to a file from one version to another.
Author: Andreas Schwab (schwab) *
Date: 2014-03-23 17:03
That's a very broad definition, I didn't know that python is such a hostile environment.
Author: Benjamin Peterson (benjamin.peterson) *
Date: 2014-03-23 17:06
Ignore Mark Lawrence.
Author: Georg Brandl (georg.brandl) *
Date: 2014-03-23 17:10
@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.
Author: Mark Lawrence (BreamoreBoy) *
Date: 2014-03-23 17:17
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.
Author: Stefan Krah (skrah) *
Date: 2014-03-23 17:25
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.
Author: Georg Brandl (georg.brandl) *
Date: 2014-03-23 17:26
With respect, Mark, I think you should leave these considerations to the committers.
Author: Mark Lawrence (BreamoreBoy) *
Date: 2014-03-23 17:31
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.
Author: Larry Hastings (larry) *
Date: 2014-03-23 21:51
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.
Author: Georg Brandl (georg.brandl) *
Date: 2014-03-23 22:10
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.)
Author: Mark Lawrence (BreamoreBoy) *
Date: 2014-03-23 22:21
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?
Author: Antoine Pitrou (pitrou) *
Date: 2014-03-23 22:24
I've asked a simple question and I've NOT had an answer.
Can we move along, please?
Author: Georg Brandl (georg.brandl) *
Date: 2014-03-23 22:30
Can we move along, please?
Indeed. Further discussion, if felt to be really necessary, should take place on python-dev.
Author: Martin v. Löwis (loewis) *
Date: 2014-03-23 22:38
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.
Author: Larry Hastings (larry) *
Date: 2014-03-24 02:07
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.
Author: Mark Dickinson (mark.dickinson) *
Date: 2014-03-24 09:56
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).
Author: Andreas Schwab (schwab) *
Date: 2014-03-24 10:28
It's not just cosmetic, it's breaking the testsuite back and forth.
Author: Mark Dickinson (mark.dickinson) *
Date: 2014-03-24 10:36
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.
Author: Mark Dickinson (mark.dickinson) *
Date: 2014-03-24 10:38
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?
Author: Andreas Schwab (schwab) *
Date: 2014-03-24 10:48
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.
Author: Mark Dickinson (mark.dickinson) *
Date: 2014-03-24 10:52
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.
Author: Andreas Schwab (schwab) *
Date: 2014-03-24 10:57
I guess they will get fixed over time, or declared unsupported. :-)
Author: Mark Dickinson (mark.dickinson) *
Date: 2014-03-24 11:15
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.
Author: Larry Hastings (larry) *
Date: 2014-03-24 20:17
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.
Author: Andreas Schwab (schwab) *
Date: 2014-03-24 20:36
That's what I call hostile.
Author: Benjamin Peterson (benjamin.peterson) *
Date: 2014-03-24 20:40
This is a short and straightforward patch that improves the Python experience for m86k users. I think it should be applied.
Author: Larry Hastings (larry) *
Date: 2014-03-24 20:49
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.
Author: Benjamin Peterson (benjamin.peterson) *
Date: 2014-03-24 20:50
Well, no one has produced a reference for this phantom announcement.
Author: Larry Hastings (larry) *
Date: 2014-03-24 20:52
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?
Author: Benjamin Peterson (benjamin.peterson) *
Date: 2014-03-24 20:54
I don't want to scare away contributors.
Author: Tim Peters (tim.peters) *
Date: 2014-03-24 21:20
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 ;-)
Author: Antoine Pitrou (pitrou) *
Date: 2014-03-24 21:21
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".
Author: Martin v. Löwis (loewis) *
Date: 2014-03-24 21:32
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.
Author: Martin v. Löwis (loewis) *
Date: 2014-03-24 21:56
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
Author: Andreas Schwab (schwab) *
Date: 2014-03-24 22:18
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).
Author: Stefan Krah (skrah) *
Date: 2014-03-24 23:05
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 (), 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).
Author: Benjamin Peterson (benjamin.peterson) *
Date: 2014-03-25 00:27
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
Author: Larry Hastings (larry) *
Date: 2014-03-26 11:26
(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.
Author: Andreas Schwab (schwab) *
Date: 2014-03-28 16:08
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
Author: mirabilos (mirabilos)
Date: 2014-04-03 21:35
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.)
Author: Andreas Schwab (schwab) *
Date: 2014-04-03 22:13
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.
Author: mirabilos (mirabilos)
Date: 2014-04-03 22:42
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 ;)
Author: Andreas Schwab (schwab) *
Date: 2014-04-03 23:18
There is no excuse for using a broken emulator.
Author: mirabilos (mirabilos)
Date: 2014-04-03 23:42
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.
Author: Andreas Schwab (schwab) *
Date: 2014-04-04 06:55
Finn Thain <fthain@telegraphics.com.au> writes:
until Aranym gets fixed.
Aranym is fixed.
Andreas.
Author: mirabilos (mirabilos)
Date: 2014-04-04 08:06
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
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 ;)
Author: Andreas Schwab (schwab) *
Date: 2014-04-04 08:21
The fixed version is here: git://git.code.sf.net/p/aranym/code
Andreas.
Author: Stefan Krah (skrah) *
Date: 2014-04-04 09:18
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.
Author: Andreas Schwab (schwab) *
Date: 2014-04-04 09:39
There is nothing that fails. The emulator has always correctly implemented the insn.
Author: mirabilos (mirabilos)
Date: 2014-04-04 21:30
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 ;)
Author: mirabilos (mirabilos)
Date: 2014-04-04 21:42
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 ;)
Author: Larry Hastings (larry) *
Date: 2014-04-04 21:48
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.
Author: Andreas Schwab (schwab) *
Date: 2014-04-09 16:38
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.
Author: Mark Dickinson (mark.dickinson) *
Date: 2014-04-09 17:23
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?
Author: Larry Hastings (larry) *
Date: 2014-04-16 23:19
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?
Author: Stefan Krah (skrah) *
Date: 2014-04-16 23:23
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. :)
Author: Roundup Robot (python-dev) 
Date: 2014-04-17 04:00
New changeset c2f6551c9eaf by Benjamin Peterson in branch 'default': support setting fpu precision on m68k (closes #20904) http://hg.python.org/cpython/rev/c2f6551c9eaf
Author: Mark Dickinson (mark.dickinson) *
Date: 2014-04-17 16:43
Yay! Thanks, Benjamin.
History
Date
User
Action
Args
2022-04-11 14:57:59
admin
set
github: 65103
2014-05-13 22:30:38
skrah
link
2014-04-17 16:43:03
mark.dickinson
set
messages: +
2014-04-17 04:00:54
python-dev
set
status: open -> closed
nosy: + python-dev
messages: +
resolution: fixed
stage: patch review -> resolved
2014-04-16 23:23:00
skrah
set
messages: +
2014-04-16 23:19:17
larry
set
messages: +
2014-04-09 17:23:26
mark.dickinson
set
messages: +
2014-04-09 16:38:29
schwab
set
messages: +
2014-04-04 21:48:09
larry
set
messages: +
2014-04-04 21:42:22
mirabilos
set
messages: +
2014-04-04 21:30:20
mirabilos
set
messages: +
2014-04-04 09:39:23
schwab
set
messages: +
2014-04-04 09🔞15
skrah
set
messages: +
2014-04-04 08:21:12
schwab
set
messages: +
2014-04-04 08:06:20
mirabilos
set
messages: +
2014-04-04 06:55:45
schwab
set
messages: +
2014-04-03 23:42:21
mirabilos
set
messages: +
2014-04-03 23🔞33
schwab
set
messages: +
2014-04-03 22:42:18
mirabilos
set
messages: +
2014-04-03 22:13:16
schwab
set
messages: +
2014-04-03 21:35:23
mirabilos
set
nosy: + mirabilos
messages: +
2014-03-28 16:08:13
schwab
set
messages: +
2014-03-26 11:26:43
larry
set
messages: +
2014-03-25 00:27:56
benjamin.peterson
set
messages: +
2014-03-24 23:05:51
skrah
set
messages: +
2014-03-24 22🔞50
schwab
set
messages: +
2014-03-24 21:56:00
loewis
set
messages: +
2014-03-24 21:32:40
loewis
set
messages: +
2014-03-24 21:21:05
pitrou
set
messages: +
2014-03-24 21:20:34
tim.peters
set
messages: +
2014-03-24 20:54:41
benjamin.peterson
set
messages: +
2014-03-24 20:52:20
larry
set
messages: +
2014-03-24 20:50:42
benjamin.peterson
set
messages: +
2014-03-24 20:49:56
larry
set
messages: +
2014-03-24 20:40:09
benjamin.peterson
set
messages: +
2014-03-24 20:36:38
schwab
set
messages: +
2014-03-24 20:17:32
larry
set
messages: +
versions: - Python 3.4
2014-03-24 11:15:15
mark.dickinson
set
messages: +
2014-03-24 10:58:13
Arfrever
set
nosy: + Arfrever
2014-03-24 10:57:21
schwab
set
messages: +
2014-03-24 10:52:43
mark.dickinson
set
messages: +
2014-03-24 10:48:48
schwab
set
messages: +
2014-03-24 10:38:43
mark.dickinson
set
messages: +
2014-03-24 10:36:53
mark.dickinson
set
messages: +
2014-03-24 10:28:57
schwab
set
messages: +
2014-03-24 09:56:50
mark.dickinson
set
messages: +
2014-03-24 02:07:34
larry
set
messages: +
2014-03-23 22:38:32
loewis
set
nosy: + loewis
messages: +
2014-03-23 22:30:44
georg.brandl
set
messages: +
2014-03-23 22:24:58
pitrou
set
messages: +
2014-03-23 22:21:50
BreamoreBoy
set
messages: +
2014-03-23 22:10:31
georg.brandl
set
messages: +
2014-03-23 22:08:45
skrah
set
stage: patch review
versions: + Python 3.5, - Python 3.3
2014-03-23 21:51:51
larry
set
messages: +
2014-03-23 17:31:25
BreamoreBoy
set
messages: +
2014-03-23 17:26:35
georg.brandl
set
messages: +
2014-03-23 17:25:15
skrah
set
messages: +
2014-03-23 17:17:59
BreamoreBoy
set
messages: +
2014-03-23 17:10:47
georg.brandl
set
nosy: + georg.brandl
messages: +
2014-03-23 17:06:01
benjamin.peterson
set
nosy: + benjamin.peterson
messages: +
2014-03-23 17:03:37
schwab
set
messages: +
2014-03-23 17:00:17
BreamoreBoy
set
messages: +
2014-03-23 16:57:02
schwab
set
messages: +
2014-03-23 16:53:56
BreamoreBoy
set
nosy: + BreamoreBoy
messages: +
2014-03-23 16:47:09
schwab
set
versions: + Python 3.4
2014-03-23 16:46:03
schwab
set
files: - m68k-float-prec.patch
2014-03-14 12:54:04
larry
set
messages: +
2014-03-14 10:13:48
pitrou
set
nosy: + pitrou
messages: +
2014-03-14 06:43:37
schwab
set
files: + m68k-float-prec.patch
messages: +
2014-03-13 18:19:24
larry
set
nosy: + larry
messages: +
2014-03-13 18:16:01
skrah
set
messages: +
2014-03-13 17:58:02
schwab
set
messages: +
2014-03-13 17:27:53
mark.dickinson
set
messages: +
2014-03-13 08:00:31
pitrou
set
nosy: + tim.peters, mark.dickinson, skrah
2014-03-13 07:54:56
schwab
create