Re: [Python-Dev] --with-fpectl changes the CPython ABI
On Sun, Dec 25, 2016 at 5:55 PM, Nick Coghlan wrote: > On 25 December 2016 at 09:48, Nathaniel Smith wrote: >> >> Or maybe make it so that even no-fpectl builds still export the >> necessary symbols so that yes-fpectl extensions don't crash on import? >> (This has the advantage that it can be done in a point release...) > > > This seems like a sensible thing to do in 3.6, 3.5 and 2.7 regardless of > what happens in 3.7. > > For 3.7, I don't understand the trade-offs well enough to have a strong > opinion, but dropping the feature entirely does seem reasonable - folks that > want fine-grained floating point exception control these days are likely to > be much better served by the decimal module, or one of the third party > computing libraries (numpy, gmpy, sympy, etc). I looked into this a bit more. I think the way it's *supposed* to work is that normally, various operations in Python might return inf or nan, but if you call fpectl.turnon_sigfpe() then they switch to raising exceptions instead. But AFAICT the fpectl module: 1) is totally broken on major platforms: There doesn't seem to be any implementation at all for MacOS. On x86/x86-64 Linux it works by fiddling with the x87 control word directly... which is okay for traditional x86 with SSE disabled, but on x86-64, or x86 with SSE enabled, then there are two separate floating point units on the processor (the old x87 FPU, and the new SSE unit), and which one gets used for any given operation is up to the C compiler. So on Linux, whether fpectl actually affects any given floating point operation is dependent on basically the phase of the moon. This is pretty bad. 2) doesn't seem to actually accomplish anything even when it does work: Back in the old days, math.exp(1000) apparently returned inf (there's a REPL transcript showing this at the top of the fpectl documentation). But nowadays math.exp raises an exception in cases where it used to return inf, regardless of fpectl. I haven't been able to find any cases where fpectl actually... does anything? 3) ...except that it does break numpy and any other code that expects the default IEEE-754 semantics: The way fpectl works is that it twiddles with the FP control word, which is a thread-global variable. After you call turnon_sigfpe(), then *any* floating point code in that thread that happens to generate a nan or inf instead triggers a SIGFPE, and if the code isn't specifically written to use the PyFPE_* macros then this causes a process abort. For example: ~$ python Python 3.5.2+ (default, Dec 13 2016, 14:16:35) [GCC 6.2.1 20161124] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import numpy as np >>> np.longdouble(1) / np.longdouble(0) __main__:1: RuntimeWarning: divide by zero encountered in longdouble_scalars inf >>> import fpectl >>> fpectl.turnon_sigfpe() >>> np.longdouble(1) / np.longdouble(0) Fatal Python error: Unprotected floating point exception Current thread 0x7fea57a9f700 (most recent call first): File "", line 1 in zsh: abort python ~$ (I'm using np.longdouble to work around the Linux SSE bug -- using long double forces the calculations to be done on the x87 unit. On Windows I believe it would be sufficient to just do np.array(1.0) / np.array(0.0).) So I guess that yeah, my suggestion would be to drop this feature entirely in 3.7, given that it's never been enabled by default and has been largely broken for years. Or do we still need a full deprecation cycle? -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] --with-fpectl changes the CPython ABI
On 2 January 2017 at 18:27, Nathaniel Smith wrote: > So I guess that yeah, my suggestion would be to drop this feature > entirely in 3.7, given that it's never been enabled by default and has > been largely broken for years. Or do we still need a full deprecation > cycle? > I think the existing warning in the docs and the fact it's apparently been fundamentally broken for years is sufficient justification for just dropping it entirely. An explicit deprecation warning could be added in 3.6.1 and a Py3k warning in 2.7.x, though - those changes shouldn't be difficult, and it's a nice courtesy for anyone that *is* somehow currently getting it to work. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] --with-fpectl changes the CPython ABI
I am happy to see it go. It was contributed many, many years ago by people (scientists from the early numpy world IIRC) who had a very specific use for it, but weren't really into maintaining it long-term, and I wasn't strong enough to refuse a well-meaning but poorly executed contribution at the time -- so we compromised on having the whole thing enabled through `#ifdef`. Clearly it started rotting the day I committed the code... On Mon, Jan 2, 2017 at 4:22 AM, Nick Coghlan wrote: > On 2 January 2017 at 18:27, Nathaniel Smith wrote: > >> So I guess that yeah, my suggestion would be to drop this feature >> entirely in 3.7, given that it's never been enabled by default and has >> been largely broken for years. Or do we still need a full deprecation >> cycle? >> > > I think the existing warning in the docs and the fact it's apparently been > fundamentally broken for years is sufficient justification for just > dropping it entirely. An explicit deprecation warning could be added in > 3.6.1 and a Py3k warning in 2.7.x, though - those changes shouldn't be > difficult, and it's a nice courtesy for anyone that *is* somehow currently > getting it to work. > > Cheers, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > guido%40python.org > > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] --with-fpectl changes the CPython ABI
Great, sounds like we have a plan: https://bugs.python.org/issue29137 On Mon, Jan 2, 2017 at 8:21 AM, Guido van Rossum wrote: > I am happy to see it go. It was contributed many, many years ago by people > (scientists from the early numpy world IIRC) who had a very specific use for > it, but weren't really into maintaining it long-term, and I wasn't strong > enough to refuse a well-meaning but poorly executed contribution at the time > -- so we compromised on having the whole thing enabled through `#ifdef`. > Clearly it started rotting the day I committed the code... > > On Mon, Jan 2, 2017 at 4:22 AM, Nick Coghlan wrote: >> >> On 2 January 2017 at 18:27, Nathaniel Smith wrote: >>> >>> So I guess that yeah, my suggestion would be to drop this feature >>> entirely in 3.7, given that it's never been enabled by default and has >>> been largely broken for years. Or do we still need a full deprecation >>> cycle? >> >> >> I think the existing warning in the docs and the fact it's apparently been >> fundamentally broken for years is sufficient justification for just dropping >> it entirely. An explicit deprecation warning could be added in 3.6.1 and a >> Py3k warning in 2.7.x, though - those changes shouldn't be difficult, and >> it's a nice courtesy for anyone that *is* somehow currently getting it to >> work. >> >> Cheers, >> Nick. >> >> -- >> Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia >> >> ___ >> Python-Dev mailing list >> Python-Dev@python.org >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/guido%40python.org >> > > > > -- > --Guido van Rossum (python.org/~guido) -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [RELEASED] Python 3.4.6rc1 and Python 3.5.3rc1 are now available
On behalf of the Python development community and the Python 3.4 and Python 3.5 release teams, I'm pleased to announce the availability of Python 3.4.6rc1 and Python 3.5.6rc1. Python 3.4 is now in "security fixes only" mode. This is the final stage of support for Python 3.4. Python 3.4 now only receives security fixes, not bug fixes, and Python 3.4 releases are source code only--no more official binary installers will be produced. Python 3.5 is still in active "bug fix" mode. Python 3.5.3rc1 contains many incremental improvements over Python 3.5.2. Both these releases are "release candidates". They should not be considered the final releases, although the final releases should contain only minor differences. Python users are encouraged to test with these releases and report any problems they encounter. You can find Python 3.4.6rc1 here: https://www.python.org/downloads/release/python-346rc1/ And you can find Python 3.5.3rc1 here: https://www.python.org/downloads/release/python-353rc1/ Python 3.4.6 final and Python 3.5.3 final are both scheduled for release on January 16th, 2017. Happy New Year, //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
