Re: [Python-Dev] [RELEASED] Python 3.3.0 release candidate 3
Antoine Pitrou solip...@pitrou.net wrote: Wow! I had no idea cdecimal was that close in speed to float. That's seriously impressive. I think this means the performance difference is on the same order of magnitude as the CPython interpretation overhead. Still, it's impressive indeed. Of course, if you compare a pure C program that uses libmpdec to a C program that uses floats, the difference will be much higher. Stefan Krah ___ 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] [RELEASED] Python 3.3.0
On behalf of the Python development team, I'm delighted to announce the Python 3.3.0 final release. Python 3.3 includes a range of improvements of the 3.x series, as well as easier porting between 2.x and 3.x. Major new features and changes in the 3.3 release series are: * PEP 380, syntax for delegating to a subgenerator (yield from) * PEP 393, flexible string representation (doing away with the distinction between wide and narrow Unicode builds) * A C implementation of the decimal module, with up to 120x speedup for decimal-heavy applications * The import system (__import__) now based on importlib by default * The new lzma module with LZMA/XZ support * PEP 397, a Python launcher for Windows * PEP 405, virtual environment support in core * PEP 420, namespace package support * PEP 3151, reworking the OS and IO exception hierarchy * PEP 3155, qualified name for classes and functions * PEP 409, suppressing exception context * PEP 414, explicit Unicode literals to help with porting * PEP 418, extended platform-independent clocks in the time module * PEP 412, a new key-sharing dictionary implementation that significantly saves memory for object-oriented code * PEP 362, the function-signature object * The new faulthandler module that helps diagnosing crashes * The new unittest.mock module * The new ipaddress module * The sys.implementation attribute * A policy framework for the email package, with a provisional (see PEP 411) policy that adds much improved unicode support for email header parsing * A collections.ChainMap class for linking mappings to a single unit * Wrappers for many more POSIX functions in the os and signal modules, as well as other useful functions such as sendfile() * Hash randomization, introduced in earlier bugfix releases, is now switched on by default In total, almost 500 API items are new or improved in Python 3.3. For a more extensive list of changes in 3.3.0, see http://docs.python.org/3.3/whatsnew/3.3.html To download Python 3.3.0 visit: http://www.python.org/download/releases/3.3.0/ This is a production release, please report any bugs to http://bugs.python.org/ Enjoy! -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and 3.3's contributors) ___ 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] [RELEASED] Python 3.3.0
On Sat, Sep 29, 2012 at 10:18 PM, Georg Brandl ge...@python.org wrote: On behalf of the Python development team, I'm delighted to announce the Python 3.3.0 final release. Python 3.3 includes a range of improvements of the 3.x series, as well as easier porting between 2.x and 3.x. Major new features and changes in the 3.3 release series are: * PEP 380, syntax for delegating to a subgenerator (yield from) * PEP 393, flexible string representation (doing away with the distinction between wide and narrow Unicode builds) * A C implementation of the decimal module, with up to 120x speedup for decimal-heavy applications * The import system (__import__) now based on importlib by default * The new lzma module with LZMA/XZ support * PEP 397, a Python launcher for Windows * PEP 405, virtual environment support in core * PEP 420, namespace package support * PEP 3151, reworking the OS and IO exception hierarchy * PEP 3155, qualified name for classes and functions * PEP 409, suppressing exception context * PEP 414, explicit Unicode literals to help with porting * PEP 418, extended platform-independent clocks in the time module * PEP 412, a new key-sharing dictionary implementation that significantly saves memory for object-oriented code * PEP 362, the function-signature object * The new faulthandler module that helps diagnosing crashes * The new unittest.mock module * The new ipaddress module * The sys.implementation attribute * A policy framework for the email package, with a provisional (see PEP 411) policy that adds much improved unicode support for email header parsing * A collections.ChainMap class for linking mappings to a single unit * Wrappers for many more POSIX functions in the os and signal modules, as well as other useful functions such as sendfile() * Hash randomization, introduced in earlier bugfix releases, is now switched on by default In total, almost 500 API items are new or improved in Python 3.3. For a more extensive list of changes in 3.3.0, see http://docs.python.org/3.3/whatsnew/3.3.html Redirects to http://docs.python.org/py3k/whatsnew/3.3.html: 404 Not Found. Cheers, Amit. -- http://echorand.me ___ 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] [RELEASED] Python 3.3.0
On Sat, Sep 29, 2012 at 10:37 PM, Dave Angel d...@davea.name wrote: On 09/29/2012 08:23 AM, Amit Saha wrote: On Sat, Sep 29, 2012 at 10:18 PM, Georg Brandl ge...@python.org wrote: snip For a more extensive list of changes in 3.3.0, see http://docs.python.org/3.3/whatsnew/3.3.html Redirects to http://docs.python.org/py3k/whatsnew/3.3.html: 404 Not Found. Works for me. Perhaps a momentary glitch. Yes, I clicked too soon, i guess.. -Amit. -- http://echorand.me ___ 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] [RELEASED] Python 3.3.0 release candidate 3
On 29 September 2012 10:17, Stefan Krah ste...@bytereef.org wrote: Tim Delaney timothy.c.dela...@gmail.com wrote: If those numbers are similar in other benchmarks, would it be accurate and/or reasonable to include a statement along the lines of: comparable to float performance - usually no more than 3x for calculations within the range of numbers covered by float For numerical programs, 1.4x (9 digits) to 3x (19 digits) slower would be accurate. On Windows the difference is even less. For output formatting, cdecimal is faster than float (at least it was when I posted a benchmark a couple of months ago). To me, this means that the key point is that for the casual user, float is no longer the obvious choice. You'd choose float for the convenience of a built in type, and Decimal for the more natural rounding and precision semantics. If you are sufficiently interested in performance for it to matter, you're no longer a casual user. (Up until now, I'd have said use float unless your need for the better behaviour justifies the performance loss - that's no longer the case). 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] [RELEASED] Python 3.3.0
On Sat, Sep 29, 2012 at 5:18 AM, Georg Brandl ge...@python.org wrote: On behalf of the Python development team, I'm delighted to announce the Python 3.3.0 final release. Yay :) ___ 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] [RELEASED] Python 3.3.0
On 29 September 2012 14:24, Eli Bendersky eli...@gmail.com wrote: On Sat, Sep 29, 2012 at 5:18 AM, Georg Brandl ge...@python.org wrote: On behalf of the Python development team, I'm delighted to announce the Python 3.3.0 final release. Yay :) Agreed - this is a really nice release, thanks to all who put it together. 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] [RELEASED] Python 3.3.0
Congrats Georg and team! I am incredibly proud of you all for producing such a great release. As the marketeers would say, Python 3.3 is the best Python ever! The feature list is amazing. --Guido On Sat, Sep 29, 2012 at 5:18 AM, Georg Brandl ge...@python.org wrote: On behalf of the Python development team, I'm delighted to announce the Python 3.3.0 final release. Python 3.3 includes a range of improvements of the 3.x series, as well as easier porting between 2.x and 3.x. Major new features and changes in the 3.3 release series are: * PEP 380, syntax for delegating to a subgenerator (yield from) * PEP 393, flexible string representation (doing away with the distinction between wide and narrow Unicode builds) * A C implementation of the decimal module, with up to 120x speedup for decimal-heavy applications * The import system (__import__) now based on importlib by default * The new lzma module with LZMA/XZ support * PEP 397, a Python launcher for Windows * PEP 405, virtual environment support in core * PEP 420, namespace package support * PEP 3151, reworking the OS and IO exception hierarchy * PEP 3155, qualified name for classes and functions * PEP 409, suppressing exception context * PEP 414, explicit Unicode literals to help with porting * PEP 418, extended platform-independent clocks in the time module * PEP 412, a new key-sharing dictionary implementation that significantly saves memory for object-oriented code * PEP 362, the function-signature object * The new faulthandler module that helps diagnosing crashes * The new unittest.mock module * The new ipaddress module * The sys.implementation attribute * A policy framework for the email package, with a provisional (see PEP 411) policy that adds much improved unicode support for email header parsing * A collections.ChainMap class for linking mappings to a single unit * Wrappers for many more POSIX functions in the os and signal modules, as well as other useful functions such as sendfile() * Hash randomization, introduced in earlier bugfix releases, is now switched on by default In total, almost 500 API items are new or improved in Python 3.3. For a more extensive list of changes in 3.3.0, see http://docs.python.org/3.3/whatsnew/3.3.html To download Python 3.3.0 visit: http://www.python.org/download/releases/3.3.0/ This is a production release, please report any bugs to http://bugs.python.org/ Enjoy! -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and 3.3's contributors) ___ 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/guido%40python.org -- --Guido van Rossum (python.org/~guido) ___ 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] [RELEASED] Python 3.3.0
On 09/29/2012 08:23 AM, Amit Saha wrote: On Sat, Sep 29, 2012 at 10:18 PM, Georg Brandl ge...@python.org wrote: snip For a more extensive list of changes in 3.3.0, see http://docs.python.org/3.3/whatsnew/3.3.html Redirects to http://docs.python.org/py3k/whatsnew/3.3.html: 404 Not Found. Works for me. Perhaps a momentary glitch. -- DaveA ___ 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] [RELEASED] Python 3.3.0
Agreed - this is a really nice release, thanks to all who put it together. +1 Thank you! Malcolm ___ 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] [RELEASED] Python 3.3.0
Hello, I've created a 3.3 category on the buildbots: http://buildbot.python.org/3.3/ http://buildbot.python.org/3.3.stable/ Someone will have to update the following HTML page: http://python.org/dev/buildbot/ Regards Antoine. On Sat, 29 Sep 2012 14:18:54 +0200 Georg Brandl ge...@python.org wrote: On behalf of the Python development team, I'm delighted to announce the Python 3.3.0 final release. Python 3.3 includes a range of improvements of the 3.x series, as well as easier porting between 2.x and 3.x. Major new features and changes in the 3.3 release series are: * PEP 380, syntax for delegating to a subgenerator (yield from) * PEP 393, flexible string representation (doing away with the distinction between wide and narrow Unicode builds) * A C implementation of the decimal module, with up to 120x speedup for decimal-heavy applications * The import system (__import__) now based on importlib by default * The new lzma module with LZMA/XZ support * PEP 397, a Python launcher for Windows * PEP 405, virtual environment support in core * PEP 420, namespace package support * PEP 3151, reworking the OS and IO exception hierarchy * PEP 3155, qualified name for classes and functions * PEP 409, suppressing exception context * PEP 414, explicit Unicode literals to help with porting * PEP 418, extended platform-independent clocks in the time module * PEP 412, a new key-sharing dictionary implementation that significantly saves memory for object-oriented code * PEP 362, the function-signature object * The new faulthandler module that helps diagnosing crashes * The new unittest.mock module * The new ipaddress module * The sys.implementation attribute * A policy framework for the email package, with a provisional (see PEP 411) policy that adds much improved unicode support for email header parsing * A collections.ChainMap class for linking mappings to a single unit * Wrappers for many more POSIX functions in the os and signal modules, as well as other useful functions such as sendfile() * Hash randomization, introduced in earlier bugfix releases, is now switched on by default In total, almost 500 API items are new or improved in Python 3.3. For a more extensive list of changes in 3.3.0, see http://docs.python.org/3.3/whatsnew/3.3.html To download Python 3.3.0 visit: http://www.python.org/download/releases/3.3.0/ This is a production release, please report any bugs to http://bugs.python.org/ Enjoy! -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and 3.3's contributors) -- Software development and contracting: http://pro.pitrou.net ___ 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] [RELEASED] Python 3.3.0
On Sat, Sep 29, 2012 at 5:18 AM, Georg Brandl ge...@python.org wrote: In total, almost 500 API items are new or improved in Python 3.3. For a more extensive list of changes in 3.3.0, see http://docs.python.org/3.3/whatsnew/3.3.html Reading this to see if I missed anything while downloading the new release: I found: For the common user, this change should result in no visible change in semantics. Any possible changes required in one’s code to handle this change should read the Porting Python code http://docs.python.org/py3k/whatsnew/3.3.html#porting-python-code section of this document to see what needs to be changed, but it will only affect those that currently manipulate import or try calling it programmatically. Sentence two in this paragraph has bizarre structure, probably due to being changed from one perspective to another. Suggestion (which turns out to be briefer): For the common user, this change should result in no visible change in semantics. Any code changes required are described in the Porting Python code http://docs.python.org/py3k/whatsnew/3.3.html#porting-python-code section of this document; it will only affect code that currently manipulates import or calls it programmatically. ___ 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] str.format bug again
2012/9/28 Ben Wolfson wolf...@gmail.com: There's a patch for this bug: http://bugs.python.org/issue12014 that needs reviewed. Petri Lehtinen made some (very minor) comments back in May; otherwise it's been neglected. I've brought this up occasionally here in the past; it would be great if someone could just give it a thumbs up or down (or say what needs to be changed, or whatever). It seems like Eric Smith is the one needs to make a decision. -- 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] str.format bug again
On Sat, Sep 29, 2012 at 10:59 AM, Benjamin Peterson benja...@python.org wrote: 2012/9/28 Ben Wolfson wolf...@gmail.com: There's a patch for this bug: http://bugs.python.org/issue12014 that needs reviewed. Petri Lehtinen made some (very minor) comments back in May; otherwise it's been neglected. I've brought this up occasionally here in the past; it would be great if someone could just give it a thumbs up or down (or say what needs to be changed, or whatever). It seems like Eric Smith is the one needs to make a decision. Yes, but one of the things he could decide is that someone else should make the decision because PEP 420 is too involved (though it was last modified in June, so who knows). -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] ___ 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] [RELEASED] Python 3.3.0 release candidate 3
On Sat, Sep 29, 2012 at 9:07 AM, Paul Moore p.f.mo...@gmail.com wrote: On 29 September 2012 10:17, Stefan Krah ste...@bytereef.org wrote: Tim Delaney timothy.c.dela...@gmail.com wrote: If those numbers are similar in other benchmarks, would it be accurate and/or reasonable to include a statement along the lines of: comparable to float performance - usually no more than 3x for calculations within the range of numbers covered by float For numerical programs, 1.4x (9 digits) to 3x (19 digits) slower would be accurate. On Windows the difference is even less. For output formatting, cdecimal is faster than float (at least it was when I posted a benchmark a couple of months ago). To me, this means that the key point is that for the casual user, float is no longer the obvious choice. You'd choose float for the convenience of a built in type, and Decimal for the more natural rounding and precision semantics. If you are sufficiently interested in performance for it to matter, you're no longer a casual user. (Up until now, I'd have said use float unless your need for the better behaviour justifies the performance loss - that's no longer the case) Does this mean we want to re-open the discussion about decimal constants? Last time this came up I think we decided that we wanted to wait for cdecimal (which is obviously here) and work out how to handle contexts, the syntax, etc. ___ 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] [RELEASED] Python 3.3.0
On Sat, 29 Sep 2012 10:46:37 -0700, Glenn Linderman v+pyt...@g.nevcal.com wrote: On Sat, Sep 29, 2012 at 5:18 AM, Georg Brandl ge...@python.org wrote: In total, almost 500 API items are new or improved in Python 3.3. For a more extensive list of changes in 3.3.0, see http://docs.python.org/3.3/whatsnew/3.3.html Reading this to see if I missed anything while downloading the new release: I found: For the common user, this change should result in no visible change in semantics. Any possible changes required in oneâs code to handle this change should read the Porting Python code http://docs.python.org/py3k/whatsnew/3.3.html#porting-python-code section of this document to see what needs to be changed, but it will only affect those that currently manipulate import or try calling it programmatically. Sentence two in this paragraph has bizarre structure, probably due to being changed from one perspective to another. Suggestion (which turns out to be briefer): For the common user, this change should result in no visible change in semantics. Any code changes required are described in the Porting Python code http://docs.python.org/py3k/whatsnew/3.3.html#porting-python-code section of this document; it will only affect code that currently manipulates import or calls it programmatically. I fixed this, though with a different wording change. --David ___ 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] [RELEASED] Python 3.3.0 release candidate 3
On Sat, Sep 29, 2012 at 11:26 AM, Brett Cannon br...@python.org wrote: On Sat, Sep 29, 2012 at 9:07 AM, Paul Moore p.f.mo...@gmail.com wrote: On 29 September 2012 10:17, Stefan Krah ste...@bytereef.org wrote: Tim Delaney timothy.c.dela...@gmail.com wrote: If those numbers are similar in other benchmarks, would it be accurate and/or reasonable to include a statement along the lines of: comparable to float performance - usually no more than 3x for calculations within the range of numbers covered by float For numerical programs, 1.4x (9 digits) to 3x (19 digits) slower would be accurate. On Windows the difference is even less. For output formatting, cdecimal is faster than float (at least it was when I posted a benchmark a couple of months ago). To me, this means that the key point is that for the casual user, float is no longer the obvious choice. You'd choose float for the convenience of a built in type, and Decimal for the more natural rounding and precision semantics. If you are sufficiently interested in performance for it to matter, you're no longer a casual user. (Up until now, I'd have said use float unless your need for the better behaviour justifies the performance loss - that's no longer the case) Does this mean we want to re-open the discussion about decimal constants? Last time this came up I think we decided that we wanted to wait for cdecimal (which is obviously here) and work out how to handle contexts, the syntax, etc. I think that ought to be a Python 4 feature if we ever want it to be a feature. And I'm not saying this to kill the discussion; I just think it will be a huge change that we have to consider very carefully. While the existing float definitely has problems for beginners, it is incredibly useful for advanced users. Consider e.g. the implications for numpy / scipy, one of the fastest-growing specialized Python user communities. Now if you want to introduce a new notation for decimals, e.g. 3.14d and 1e42d, that would be a fine thing. (Should we also have complex decimals? 1jd anyone?) -- --Guido van Rossum (python.org/~guido) ___ 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] [RELEASED] Python 3.3.0 release candidate 3
On Sun, Sep 30, 2012 at 4:26 AM, Brett Cannon br...@python.org wrote: Does this mean we want to re-open the discussion about decimal constants? Last time this came up I think we decided that we wanted to wait for cdecimal (which is obviously here) and work out how to handle contexts, the syntax, etc. Just to throw a crazy idea out: How bad a change would it be to make decimal actually the default? (Caveat: I've not worked with decimal/cdecimal to any real extent and don't know its limitations etc.) ChrisA ___ 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] str.format bug again
It's on my list of things to look at. I have a project due next week, then I'll have some time. -- Eric. On Sep 29, 2012, at 2:11 PM, Ben Wolfson wolf...@gmail.com wrote: On Sat, Sep 29, 2012 at 10:59 AM, Benjamin Peterson benja...@python.org wrote: 2012/9/28 Ben Wolfson wolf...@gmail.com: There's a patch for this bug: http://bugs.python.org/issue12014 that needs reviewed. Petri Lehtinen made some (very minor) comments back in May; otherwise it's been neglected. I've brought this up occasionally here in the past; it would be great if someone could just give it a thumbs up or down (or say what needs to be changed, or whatever). It seems like Eric Smith is the one needs to make a decision. Yes, but one of the things he could decide is that someone else should make the decision because PEP 420 is too involved (though it was last modified in June, so who knows). -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] ___ 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/eric%2Ba-python-dev%40trueblade.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] make decimal the default non-integer instead of float?
-cc: python-dev +cc: python-ideas On Sat, Sep 29, 2012 at 11:39 AM, Chris Angelico ros...@gmail.com wrote: On Sun, Sep 30, 2012 at 4:26 AM, Brett Cannon br...@python.org wrote: Does this mean we want to re-open the discussion about decimal constants? Last time this came up I think we decided that we wanted to wait for cdecimal (which is obviously here) and work out how to handle contexts, the syntax, etc. Just to throw a crazy idea out: How bad a change would it be to make decimal actually the default? (Caveat: I've not worked with decimal/cdecimal to any real extent and don't know its limitations etc.) Painful for existing code, unittests and extension modules. Definitely python-ideas territory (thread moved there with an appropriate subject). I'm not surprised at all that a decimal type can be fast in an interpreted language due to the already dominant interpreter overhead. I wish all spreadsheets had used decimals from day one rather than binary floating point (blame Lotus?). Think of the trouble that would have saved the world. -gps ___ 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] [RELEASED] Python 3.3.0 release candidate 3
BTW, What's New: http://www.python.org/download/releases/3.3.0/ still says 80x for decimal performance. Tim Delaney ___ 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] [RELEASED] Python 3.3.0 release candidate 3
Also the example at http://docs.python.org/py3k/whatsnew/3.3.html#pep-409-suppressing-exception-contextreads: ... raise AttributeError(attr) from None... Looks like there's an elipsis there that shouldn't be. Tim Delaney ___ 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] [RELEASED] Python 3.3.0 release candidate 3
In article can8clgmmfvvxmxu8nsme9uphooyaevxmjd81mphmszoqsv5...@mail.gmail.com, Tim Delaney timothy.c.dela...@gmail.com wrote: BTW, What's New: http://www.python.org/download/releases/3.3.0/ still says 80x for decimal performance. Thanks for the report. The page has now been updated to match the final 3.3.0 release announcement post. -- 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] [RELEASED] Python 3.3.0 release candidate 3
On Sep 29, 2012 2:38 PM, Guido van Rossum gu...@python.org wrote: On Sat, Sep 29, 2012 at 11:26 AM, Brett Cannon br...@python.org wrote: On Sat, Sep 29, 2012 at 9:07 AM, Paul Moore p.f.mo...@gmail.com wrote: On 29 September 2012 10:17, Stefan Krah ste...@bytereef.org wrote: Tim Delaney timothy.c.dela...@gmail.com wrote: If those numbers are similar in other benchmarks, would it be accurate and/or reasonable to include a statement along the lines of: comparable to float performance - usually no more than 3x for calculations within the range of numbers covered by float For numerical programs, 1.4x (9 digits) to 3x (19 digits) slower would be accurate. On Windows the difference is even less. For output formatting, cdecimal is faster than float (at least it was when I posted a benchmark a couple of months ago). To me, this means that the key point is that for the casual user, float is no longer the obvious choice. You'd choose float for the convenience of a built in type, and Decimal for the more natural rounding and precision semantics. If you are sufficiently interested in performance for it to matter, you're no longer a casual user. (Up until now, I'd have said use float unless your need for the better behaviour justifies the performance loss - that's no longer the case) Does this mean we want to re-open the discussion about decimal constants? Last time this came up I think we decided that we wanted to wait for cdecimal (which is obviously here) and work out how to handle contexts, the syntax, etc. I think that ought to be a Python 4 feature if we ever want it to be a feature. And I'm not saying this to kill the discussion; I just think it will be a huge change that we have to consider very carefully. While the existing float definitely has problems for beginners, it is incredibly useful for advanced users. Consider e.g. the implications for numpy / scipy, one of the fastest-growing specialized Python user communities. Now if you want to introduce a new notation for decimals, e.g. 3.14d and 1e42d, that would be a fine thing. (Should we also have complex decimals? 1jd anyone?) That's actually what I meant and not replacing floats (unless a command line flag was used); sorry if that wasn't clear. -brett -- --Guido van Rossum (python.org/~guido) ___ 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] Decimal(2) != float(2)???
Hello, In http://docs.python.org/release/3.2.3/reference/expressions.html#in we read: [...] This can create the illusion of non-transitivity between supported cross-type comparisons and unsupported comparisons. For example, Decimal(2) == 2 and 2 == float(2) but Decimal(2) != float(2). (The same is in the 3.3 docs). But: Python 3.2.3 (default, Sep 10 2012, 18:14:40) [GCC 4.6.3] on linux2 Type help, copyright, credits or license for more information. import decimal decimal.Decimal(2) == float(2) True Is it a bug in the docs or in Python itself? (I checked that in 3.2, but it may be true for 3.3 as well) Regards. *j ___ 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] Decimal(2) != float(2)???
On 2012-09-30 01:43, Jan Kaliszewski wrote:
Hello,
In http://docs.python.org/release/3.2.3/reference/expressions.html#in
we read: [...] This can create the illusion of non-transitivity between
supported cross-type comparisons and unsupported comparisons. For
example, Decimal(2) == 2 and 2 == float(2) but Decimal(2) != float(2).
(The same is in the 3.3 docs).
But:
Python 3.2.3 (default, Sep 10 2012, 18:14:40)
[GCC 4.6.3] on linux2
Type help, copyright, credits or license for more
information.
import decimal
decimal.Decimal(2) == float(2)
True
Is it a bug in the docs or in Python itself? (I checked that in 3.2,
but it may be true for 3.3 as well)
It's the same in Python 3.3:
decimal.Decimal(2) == float(2)
True
Also:
decimal.Decimal(0.1) == 0.1
True
decimal.Decimal(0.1) == 0.1
False
This is because floats work in binary:
decimal.Decimal(0.1) # from a float
Decimal('0.155511151231257827021181583404541015625')
decimal.Decimal(0.1)
Decimal('0.1')
___
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] Decimal(2) != float(2)???
On 30/09/12 10:43, Jan Kaliszewski wrote: Hello, In http://docs.python.org/release/3.2.3/reference/expressions.html#in we read: [...] This can create the illusion of non-transitivity between supported cross-type comparisons and unsupported comparisons. For example, Decimal(2) == 2 and 2 == float(2) but Decimal(2) != float(2). [...] Is it a bug in the docs or in Python itself? (I checked that in 3.2, but it may be true for 3.3 as well) Documentation bug. It used to be the case that Decimal and float did not compare equal: steve@runes:~$ python3.1 Python 3.1.3 (r313:86834, Nov 28 2010, 11:28:10) [GCC 4.4.5] on linux2 Type help, copyright, credits or license for more information. py from decimal import Decimal py Decimal(2) == 2.0 False but starting in 3.2 they do. But of course there are traps for the unwary, due to binary floats, e.g. Decimal(0.1) != 0.1 -- Steven ___ 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] [RELEASED] Python 3.3.0 release candidate 3
On Sun, 30 Sep 2012 08:01:00 +1000, Tim Delaney timothy.c.dela...@gmail.com wrote: Also the example at http://docs.python.org/py3k/whatsnew/3.3.html#pep-409-suppressing-exception-contextreads: ... raise AttributeError(attr) from None... Looks like there's an elipsis there that shouldn't be. This appears to be a Sphinx bug of some sort. The ReST source is correct. --David ___ 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] [RELEASED] Python 3.3.0 release candidate 3
On Sat, Sep 29, 2012 at 10:09 PM, R. David Murray rdmur...@bitdance.com wrote: On Sun, 30 Sep 2012 08:01:00 +1000, Tim Delaney timothy.c.dela...@gmail.com wrote: Also the example at http://docs.python.org/py3k/whatsnew/3.3.html#pep-409-suppressing-exception-contextreads: ... raise AttributeError(attr) from None... Looks like there's an elipsis there that shouldn't be. This appears to be a Sphinx bug of some sort. The ReST source is correct. Yes, this was previously discussed here: http://mail.python.org/pipermail/python-dev/2012-August/121467.html where Georg wrote: this is fixed in the latest Pygments, and will be fine in the doc once I update its version used for building. Until then, you could disable syntax highlighting on that particular code block. --Chris ___ 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] Decimal(2) != float(2)???
On 9/29/2012 11:48 PM, Steven D'Aprano wrote: On 30/09/12 10:43, Jan Kaliszewski wrote: Hello, In http://docs.python.org/release/3.2.3/reference/expressions.html#in we read: [...] This can create the illusion of non-transitivity between supported cross-type comparisons and unsupported comparisons. For example, Decimal(2) == 2 and 2 == float(2) but Decimal(2) != float(2). [...] Is it a bug in the docs or in Python itself? (I checked that in 3.2, but it may be true for 3.3 as well) Documentation bug. It used to be the case that Decimal and float did not compare equal: Questions about past releases are better directed to python-list (where Steven would have given same answer ;-). But anyway, please open a doc issue on the tracker to update that item. steve@runes:~$ python3.1 Python 3.1.3 (r313:86834, Nov 28 2010, 11:28:10) [GCC 4.4.5] on linux2 Type help, copyright, credits or license for more information. py from decimal import Decimal py Decimal(2) == 2.0 False but starting in 3.2 they do. But of course there are traps for the unwary, due to binary floats, e.g. Decimal(0.1) != 0.1 -- Terry Jan Reedy ___ 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
