Re: [Python-Dev] Shorter float repr in Python 3.1?
On 14 Apr, 2009, at 18:09, Mark Dickinson wrote: Okay, I think I might have fixed up the float endianness detection for universal builds on OS X. Ned, any chance you could give this another try with an updated version of the py3k-short-float-repr branch? One thing I don't understand: Is it true that to produce a working universal/fat build of Python, one has to first regenerate configure and pyconfig.h.in using autoconf version >= 2.62? If not, then I don't understand how the AC_C_BIGENDIAN autoconf macro can be giving the right results. It cannot, the actual bigendian detection for universal build is done in pymacconfig.h. I have given up on getting pyconfig.h right for universal builds, especially when dealing with 4-way universal builds. Ronald Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com smime.p7s Description: S/MIME cryptographic signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
I rather like supporting short float representation. Given that CPython is adopting it, I'm sure Jython will adopt this approach too as part of a future Jython 3.x release. - Jim On Tue, Apr 7, 2009 at 9:41 AM, Michael Foord wrote: > Mark Dickinson wrote: > >> [snip...] >> Discussion points >> = >> >> (1) Any objections to including this into py3k? If there's >> controversy, then I guess we'll need a PEP. >> >> > > Big +1 > >> (2) Should other Python implementations (Jython, >> IronPython, etc.) be expected to use short float repr, or should >> it just be considered an implementation detail of CPython? >> I propose the latter, except that all implementations should >> be required to satisfy eval(repr(x)) == x for finite floats x. >> >> > Short float repr should be an implementation detail, so long as > eval(repr(x)) == x still holds. > > Michael Foord > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/blog > > > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/jbaker%40zyasoft.com > -- Jim Baker jba...@zyasoft.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
On Tue, Apr 14, 2009 at 6:32 PM, Ned Deily wrote: > The OSX installer script is in Mac/BuildScript/build-installer.py. > > For 2-way builds, it essentially does: > > export MACOSX_DEPLOYMENT_TARGET=10.3 > configure -C --enable-framework > --enable-universalsdk=/Developer/SDKs/MacOSX10.4u.sdk > --with-universal-archs='32-bit' --with-computed-gotos OPT='-g -O3' Great---thank you! And thank you for all the testing. I'll try to sort all this out later this evening (GMT+1); I think I understand how to fix everything now. Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
On Tue, Apr 14, 2009 at 6:55 PM, "Martin v. Löwis" wrote: > The outcome of AC_C_BIGENDIAN isn't used on OSX. Depending on the exact > version you look at, things might work differently; in trunk, > Include/pymacconfig.h should be used [...] Many thanks---that was the missing piece of the puzzle. I think I understand how to make things work now. Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
> If this approach is sane, could it be adopted for all other instances of > endianness detection in the py3k code base? Don't worry - the approach that we already take is already sane, so no further changes are needed. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
> Is it true that to produce a working universal/fat build of Python, > one has to first regenerate configure and pyconfig.h.in using autoconf > version >= 2.62? If not, then I don't understand how the > AC_C_BIGENDIAN autoconf macro can be giving the right results. The outcome of AC_C_BIGENDIAN isn't used on OSX. Depending on the exact version you look at, things might work differently; in trunk, Include/pymacconfig.h should be used, which does #if defined(__APPLE__) # undef WORDS_BIGENDIAN #ifdef __BIG_ENDIAN__ #define WORDS_BIGENDIAN 1 #endif /* __BIG_ENDIAN */ #endif Earlier versions included that ifdef block directly in pyconfig.h.in. In case it isn't clear how this works: GCC predefines __BIG_ENDIAN__ on PPC but not on x86; for universal binaries, two (or more) separate preprocessor (and compiler runs) are done. HTH, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
In article <5c6f2a5d0904140930y7dc7cf4fg496d50fd34f89...@mail.gmail.com>, Mark Dickinson wrote: > Do you know the right way to create a universal build? If so, I'm in a > position > to test on 32-bit PPC, 32-bit Intel and 64-bit Intel. The OSX installer script is in Mac/BuildScript/build-installer.py. For 2-way builds, it essentially does: export MACOSX_DEPLOYMENT_TARGET=10.3 configure -C --enable-framework --enable-universalsdk=/Developer/SDKs/MacOSX10.4u.sdk --with-universal-archs='32-bit' --with-computed-gotos OPT='-g -O3' and for 4-way: export MACOSX_DEPLOYMENT_TARGET=10.5 configure -C --enable-framework --enable-universalsdk=/Developer/SDKs/MacOSX10.5.sdk --with-universal-archs='all' --with-computed-gotos OPT='-g -O3' -- Ned Deily, n...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
In article <5c6f2a5d0904140909x417d225ejd845de9c5c780...@mail.gmail.com>, Mark Dickinson wrote: > Okay, I think I might have fixed up the float endianness detection for > universal builds on OS X. Ned, any chance you could give this > another try with an updated version of the py3k-short-float-repr branch? Not looking good. Appears to be same behavior on the G4 with 10.5 (haven't tried the G3 yet). -- Ned Deily, n...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
In article , Antoine Pitrou wrote: > Has anyone tested a recent py3k using universal builds? Do all tests pass? It's done all the time. All of the current released installers (2.5, 2.6, 3.0) are 2-way (i386, ppc) universal and we occasionally test all of the current lines (2.6, trunk, 3.0, 3.1) as 4-way (i386, ppc, x86_64, ppc64), although the ppc64 has had no testing recently. -- Ned Deily, n...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
On Tue, Apr 14, 2009 at 5:49 PM, Antoine Pitrou wrote: > Mark Dickinson gmail.com> writes: >> Do you know the right way to create a universal build? > > Not at all, sorry. No problem :). I might try asking on the pythonmac-sig list. Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
Mark Dickinson gmail.com> writes: > > > Has anyone tested a recent py3k using universal builds? Do all tests pass? > > Do you know the right way to create a universal build? Not at all, sorry. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
On Tue, Apr 14, 2009 at 5:14 PM, Antoine Pitrou wrote: > If this approach is sane, could it be adopted for all other instances of > endianness detection in the py3k code base? I think everything else is fine: float endianness detection (for marshal, pickle, struct) is done at runtime. Integer endianness detection goes via AC_C_BIGENDIAN, which understands universal builds---but only for autoconf >= 2.62. > Has anyone tested a recent py3k using universal builds? Do all tests pass? Do you know the right way to create a universal build? If so, I'm in a position to test on 32-bit PPC, 32-bit Intel and 64-bit Intel. Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
Mark Dickinson gmail.com> writes: > > Okay, I think I might have fixed up the float endianness detection for > universal builds on OS X. Ned, any chance you could give this > another try with an updated version of the py3k-short-float-repr branch? If this approach is sane, could it be adopted for all other instances of endianness detection in the py3k code base? Has anyone tested a recent py3k using universal builds? Do all tests pass? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
Okay, I think I might have fixed up the float endianness detection for universal builds on OS X. Ned, any chance you could give this another try with an updated version of the py3k-short-float-repr branch? One thing I don't understand: Is it true that to produce a working universal/fat build of Python, one has to first regenerate configure and pyconfig.h.in using autoconf version >= 2.62? If not, then I don't understand how the AC_C_BIGENDIAN autoconf macro can be giving the right results. Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
On Tue, Apr 14, 2009 at 9:45 AM, Ned Deily wrote: > FIrst attempt was a fat (32-bit i386 and ppc) build on 10.5 targeted for > 10.3 and above; this is the similar to recent python.org OSX installers. What's the proper way to create such a build? I've been trying: ./configure --with-universal-archs=32-bit --enable-framework --enable-universalsdk=/ MACOSX_DEPLOYMENT_TARGET=10.5 but the configure AC_C_BIGENDIAN macro doesn't seem to pick up on the universality: the output from ./configure contains the line: checking whether byte ordering is bigendian... no I was expecting a "... universal" instead of "... no". >From reading the autoconf manual, it seems as though AC_C_BIGENDIAN knows some magic to make things work for universal builds; it ought to be possible to imitate that magic somehow. Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
Mark Dickinson gmail.com> writes: > > But I'd expect that there are already similar issues > with a 'fat' build of py3k on OS X. After all, there's > already a 'WORDS_BIGENDIAN' in pyconfig.h.in. I > don't know where this is used. It's used e.g. in unicode encoding/decoding, and in the IO lib. If that constant can't take different values depending on the CPU arch, we have a big problem. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
On Tue, Apr 14, 2009 at 11:37 AM, Mark Dickinson wrote: > By the way, a simple native build on OS X 10.4/PPC passed all tests (that > we're already failing before). s/we're/weren't ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
By the way, a simple native build on OS X 10.4/PPC passed all tests (that we're already failing before). Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
Ned Deily wrote: I'll crank up some OS X installer builds and run them on G3 and G4 Macs vs 32-/64- Intel. Any tests of interest beyond the default regttest.py? FIrst attempt was a fat (32-bit i386 and ppc) build on 10.5 targeted for 10.3 and above; this is the similar to recent python.org OSX installers. The good news: on 10.5 i386, running the default regrtest, no signficant differences were noted from an installer built from the current main py3k head. Okay, that's awesome. Thanks. Bad news: the same build installed on a G4 running 10.5 hung hard in test_pow of test_builtin; a kill was needed to terminate python. Same results on a G3 running 10.4. Okay, that's less than awesome. But still a huge thanks. Then I tried a couple of random floats: Python 3.1a2+ (py3k-short-float-repr, Apr 13 2009, 20:55:35) [GCC 4.0.1 (Apple Inc. build 5490)] on darwin Type "help", "copyright", "credits" or "license" for more information. 3.1 -9.255965342383856e+61 1. ^C Terminated <-- kill needed I don't suppose it's possible that you could run this under gdb and get a stack trace when it starts looping (assuming that's what's happening)? I think I might have a PPC Mac Mini I can get my hands on, and I'll test there if possible. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
On Tue, Apr 14, 2009 at 9:45 AM, Ned Deily wrote: > Ned Deily wrote: >> Eric Smith wrote: >> > Before then, if anyone could build and test the py3k-short-float-repr >> > branch on any of the following machines, that would be great: >> > >> [...] >> > Something bigendian, like a G4 Mac >> >> I'll crank up some OS X installer builds and run them on G3 and G4 Macs >> vs 32-/64- Intel. Any tests of interest beyond the default regttest.py? Ned, many thanks for doing this! > Then I tried a couple of random floats: > > Python 3.1a2+ (py3k-short-float-repr, Apr 13 2009, 20:55:35) > [GCC 4.0.1 (Apple Inc. build 5490)] on darwin > Type "help", "copyright", "credits" or "license" for more information. 3.1 > -9.255965342383856e+61 1. > ^C > Terminated <-- kill needed Cool! I suspect endianness issues. As evidence, I present: >>> list(struct.pack('>> list(struct.pack('http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
In article , Ned Deily wrote: > In article <49e3d34e.8040...@trueblade.com>, > Eric Smith wrote: > > Before then, if anyone could build and test the py3k-short-float-repr > > branch on any of the following machines, that would be great: > > > [...] > > Something bigendian, like a G4 Mac > > I'll crank up some OS X installer builds and run them on G3 and G4 Macs > vs 32-/64- Intel. Any tests of interest beyond the default regttest.py? FIrst attempt was a fat (32-bit i386 and ppc) build on 10.5 targeted for 10.3 and above; this is the similar to recent python.org OSX installers. The good news: on 10.5 i386, running the default regrtest, no signficant differences were noted from an installer built from the current main py3k head. Bad news: the same build installed on a G4 running 10.5 hung hard in test_pow of test_builtin; a kill was needed to terminate python. Same results on a G3 running 10.4. n...@pbg4:/Library/Frameworks/Python.framework/Versions/3.1$ bin/python -S lib/python3.1/test/regrtest.py -s -v test_builtin test_builtin test_abs (test.test_builtin.BuiltinTest) ... ok test_all (test.test_builtin.BuiltinTest) ... ok test_any (test.test_builtin.BuiltinTest) ... ok test_ascii (test.test_builtin.BuiltinTest) ... ok test_bin (test.test_builtin.BuiltinTest) ... ok test_callable (test.test_builtin.BuiltinTest) ... ok test_chr (test.test_builtin.BuiltinTest) ... ok test_cmp (test.test_builtin.BuiltinTest) ... ok test_compile (test.test_builtin.BuiltinTest) ... ok test_delattr (test.test_builtin.BuiltinTest) ... ok test_dir (test.test_builtin.BuiltinTest) ... ok test_divmod (test.test_builtin.BuiltinTest) ... ok test_eval (test.test_builtin.BuiltinTest) ... ok test_exec (test.test_builtin.BuiltinTest) ... ok test_exec_redirected (test.test_builtin.BuiltinTest) ... ok test_filter (test.test_builtin.BuiltinTest) ... ok test_general_eval (test.test_builtin.BuiltinTest) ... ok test_getattr (test.test_builtin.BuiltinTest) ... ok test_hasattr (test.test_builtin.BuiltinTest) ... ok test_hash (test.test_builtin.BuiltinTest) ... ok test_hex (test.test_builtin.BuiltinTest) ... ok test_id (test.test_builtin.BuiltinTest) ... ok test_import (test.test_builtin.BuiltinTest) ... ok test_input (test.test_builtin.BuiltinTest) ... ok test_isinstance (test.test_builtin.BuiltinTest) ... ok test_issubclass (test.test_builtin.BuiltinTest) ... ok test_iter (test.test_builtin.BuiltinTest) ... ok test_len (test.test_builtin.BuiltinTest) ... ok test_map (test.test_builtin.BuiltinTest) ... ok test_max (test.test_builtin.BuiltinTest) ... ok test_min (test.test_builtin.BuiltinTest) ... ok test_neg (test.test_builtin.BuiltinTest) ... ok test_next (test.test_builtin.BuiltinTest) ... ok test_oct (test.test_builtin.BuiltinTest) ... ok test_open (test.test_builtin.BuiltinTest) ... ok test_ord (test.test_builtin.BuiltinTest) ... ok test_pow (test.test_builtin.BuiltinTest) ... ^CTerminated Stepping through some of test_pow from the interactive interpreter: Python 3.1a2+ (py3k-short-float-repr, Apr 13 2009, 20:55:35) [GCC 4.0.1 (Apple Inc. build 5490)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> pow(0,0) 1<-- OK >>> pow(2,30) 1073741824 <-- OK >>> pow(0.,0) ^C^CTerminated <-- float argument => python hung in CPU loop, killed Then I tried a couple of random floats: Python 3.1a2+ (py3k-short-float-repr, Apr 13 2009, 20:55:35) [GCC 4.0.1 (Apple Inc. build 5490)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> 3.1 -9.255965342383856e+61 >>> 1. ^C Terminated <-- kill needed The same tests work fine on the intel Mac. Just out of curiosity, I'll try to do the same build on the 10.4 ppc; there are occasionally a few differences noted in the build results. That won't be available until later today. -- Ned Deily, n...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
Ned Deily wrote: In article <49e3d34e.8040...@trueblade.com>, Eric Smith wrote: Before then, if anyone could build and test the py3k-short-float-repr branch on any of the following machines, that would be great: [...] Something bigendian, like a G4 Mac I'll crank up some OS X installer builds and run them on G3 and G4 Macs vs 32-/64- Intel. Any tests of interest beyond the default regttest.py? Thanks! regrtest.py should be enough. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
In article <49e3d34e.8040...@trueblade.com>, Eric Smith wrote: > Before then, if anyone could build and test the py3k-short-float-repr > branch on any of the following machines, that would be great: > [...] > Something bigendian, like a G4 Mac I'll crank up some OS X installer builds and run them on G3 and G4 Macs vs 32-/64- Intel. Any tests of interest beyond the default regttest.py? -- Ned Deily, n...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
Benjamin Peterson wrote: Cool. Will you use svnmerge.py to integrate the branch? After having some odd behavior merging the io-c branch, suggest you just apply a patch to the py3k branch, We're just going to apply 2 patches, without using svnmerge. First we'll add new files and the configure changes. Once we're sure that builds everywhere, then the second step will actually hook in the new functions and will have the formatting changes. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
2009/4/13 Eric Smith : > Mark has uploaded our newest work to Rietveld, again at > http://codereview.appspot.com/33084/show. Since the last version, Mark has > added 387 support (and other fixes) and I've added localized formatting > ('n') back in as well as ',' formatting for float and int. I think this > addresses all open issues. If you have time, please review the code on > Rietveld. > > We believe we're ready to merge this back into the py3k branch. Pending any > comments here or on Rietveld, we'll do the merge in the next day or so. Cool. Will you use svnmerge.py to integrate the branch? After having some odd behavior merging the io-c branch, suggest you just apply a patch to the py3k branch, -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
Mark has uploaded our newest work to Rietveld, again at http://codereview.appspot.com/33084/show. Since the last version, Mark has added 387 support (and other fixes) and I've added localized formatting ('n') back in as well as ',' formatting for float and int. I think this addresses all open issues. If you have time, please review the code on Rietveld. We believe we're ready to merge this back into the py3k branch. Pending any comments here or on Rietveld, we'll do the merge in the next day or so. Before then, if anyone could build and test the py3k-short-float-repr branch on any of the following machines, that would be great: Windows (preferably 64-bit) Itanium Old Intel/Linux (e.g., the snakebite nitrogen box) Something bigendian, like a G4 Mac We're pretty well tested on x86 Mac and Linux, and I've run it once on my Windows 32-bit machine. I have a Snakebite account, and I'll try running on nitrogen once I figure out how to log in again. I just had Itanium and PPC buildbots test our branch, and they both succeeded (or at least failed with errors not related to our changes). Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
On Tue, Apr 07, 2009, Mark Dickinson wrote: > > Executive summary (details and discussion points below) > = > > Some time ago, Noam Raphael pointed out that for a float x, > repr(x) can often be much shorter than it currently is, without > sacrificing the property that eval(repr(x)) == x, and proposed > changing Python accordingly. See > > http://bugs.python.org/issue1580 Sounds good to me! -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ "...string iteration isn't about treating strings as sequences of strings, it's about treating strings as sequences of characters. The fact that characters are also strings is the reason we have problems, but characters are strings for other good reasons." --Aahz ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
Mark Dickinson wrote: One PyCon 2009 sprint later, Eric Smith and I have produced the py3k-short-float-repr branch, which implements short repr of floats and also does some major cleaning up of the current float formatting functions. We've gone for the {fast, correct} pairing. We'd like to get this into Python 3.1. Any thoughts/objections/counter-proposals/...? As part of the decision process, we've tried this on several buildbots, and it has been successful on at least: AMD64 Gentoo: http://www.python.org/dev/buildbot/3.x/amd64%20gentoo%203.x/builds/592 PPC Debian unstable: http://www.python.org/dev/buildbot/3.x/ppc%20Debian%20unstable%203.x/builds/584 Sparc Solaris 10: http://www.python.org/dev/buildbot/3.x/sparc%20solaris10%20gcc%203.x/builds/493 The Sparc test failed, but that wasn't our fault! Our tests succeeded. These builds are in addition to x86 Linux and x86 Mac, which we've developed on. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
It would have helped if I'd copied the list... Sorry, Paul. 2009/4/7 Paul Moore : > 2009/4/7 Michael Foord : >> Mark Dickinson wrote: >>> >>> [snip...] >>> Discussion points >>> = >>> >>> (1) Any objections to including this into py3k? If there's >>> controversy, then I guess we'll need a PEP. >>> >> >> Big +1 >>> >>> (2) Should other Python implementations (Jython, >>> IronPython, etc.) be expected to use short float repr, or should >>> it just be considered an implementation detail of CPython? >>> I propose the latter, except that all implementations should >>> be required to satisfy eval(repr(x)) == x for finite floats x. >>> >> >> Short float repr should be an implementation detail, so long as >> eval(repr(x)) == x still holds. > > What he said :-) > Paul. > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
Mark Dickinson wrote: [snip...] Discussion points = (1) Any objections to including this into py3k? If there's controversy, then I guess we'll need a PEP. Big +1 (2) Should other Python implementations (Jython, IronPython, etc.) be expected to use short float repr, or should it just be considered an implementation detail of CPython? I propose the latter, except that all implementations should be required to satisfy eval(repr(x)) == x for finite floats x. Short float repr should be an implementation detail, so long as eval(repr(x)) == x still holds. Michael Foord -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Shorter float repr in Python 3.1?
Executive summary (details and discussion points below) = Some time ago, Noam Raphael pointed out that for a float x, repr(x) can often be much shorter than it currently is, without sacrificing the property that eval(repr(x)) == x, and proposed changing Python accordingly. See http://bugs.python.org/issue1580 For example, instead of the current behaviour: Python 3.1a2+ (py3k:71353:71354, Apr 7 2009, 12:55:16) [GCC 4.0.1 (Apple Inc. build 5490)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> 0.01 0.01 >>> 0.02 0.02 >>> 0.03 0.02 >>> 0.04 0.040001 >>> 0.04 == eval(repr(0.04)) True we'd have this: Python 3.1a2+ (py3k-short-float-repr:71350:71352M, Apr 7 2009, ) [GCC 4.0.1 (Apple Inc. build 5490)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> 0.01 0.01 >>> 0.02 0.02 >>> 0.03 0.03 >>> 0.04 0.04 >>> 0.04 == eval(repr(0.04)) True Initial attempts to implement this encountered various difficulties, and at some point Tim Peters pointed out (I'm paraphrasing horribly here) that one can't have all three of {fast, easy, correct}. One PyCon 2009 sprint later, Eric Smith and I have produced the py3k-short-float-repr branch, which implements short repr of floats and also does some major cleaning up of the current float formatting functions. We've gone for the {fast, correct} pairing. We'd like to get this into Python 3.1. Any thoughts/objections/counter-proposals/...? More details Our solution is based on an adaptation of David Gay's 'perfect rounding' code for inclusion in Python. To make eval(repr(x)) roundtripping work, one needs to have correctly rounded float -> decimal *and* decimal -> float conversions: Gay's code provides correctly rounded dtoa and strtod functions for these two conversions. His code is well-known and well-tested: it's used as the basis of the glibc strtod, and is also in OS X. It's available from http://www.netlib.org/fp/dtoa.c So our branch contains a new file Python/dtoa.c, which is a cut down version of Gay's original file. (We've removed stuff for VAX and IBM floating-point formats, hex NaNs, hex floating-point formats, locale-aware interpretation of the decimal separator, K&R headers, code for correct setting of the inexact flag, and various other bits and pieces that Python doesn't care about.) Most of the rest of the work is in the existing file Python/pystrtod.c. Every float -> string or string -> float conversion goes through a function in this file at some point. Gay's code also provides the opportunity to clean up the current float formatting code, and Eric has reworked a lot of the float formatting in the py3k-short-float-repr branch. This reworking should make finishing off the implementation of things like thousands separators much more straightforward. One example of this: the previous string -> float conversion used the system strtod, which is locale-aware, so the code had to first replace the '.' by the current locale's decimal separator, *then* call strtod. There was a similar dance in the reverse direction when doing float -> string conversion. Both these are now unnecessary. The current code is pretty close to ready for merging to py3k. I've uploaded a patchset to Rietveld: http://codereview.appspot.com/33084/show Apart from the short float repr, and a couple of bugfixes, all behaviour should be unchanged from before. There are a few exceptions: - format(1e200, '<') doesn't behave quite as it did before. See item (3) below for details - repr switches to using exponential notation at 1e16 instead of the previous 1e17. This avoids a subtle issue where the 'short float repr' result is padded with bogus zeros. - a similar change applies to str, which switches to exponential notation at 1e11, not 1e12. This fixes the following minor annoyance, which goes back at least as far as Python 2.5 (and probably much further): >>> x = 1e11 + 0.5 >>> x 1000.5 >>> print(x) 1000.0 That .0 seems wrong to me: if we're going to go to the trouble of printing extra digits (str usually only gives 12 significant digits; here there are 13), they should be the *right* extra digits. Discussion points = (1) Any objections to including this into py3k? If there's controversy, then I guess we'll need a PEP. (2) Should other Python implementations (Jython, IronPython, etc.) be expected to use short float repr, or should it just be considered an implementation detail of CPython? I propose the latter, except that all implementations should be required to satisfy eval(repr(x)) == x for finite floats x. (3) There's a PEP 3101 line we don't know what to do with. In py3k, we currently have: >>> format(1e200, '<') '1.0e+200' but in our py3k-short-float-repr branch: >>> format(1e200, '<') '1e+200' Which is correct? The py3k behaviour comes from the