Re: [Python-Dev] [RELEASED] Python 3.3.0 release candidate 3

2012-09-29 Thread Stefan Krah 
Tim Delaney  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).


Stefan Krah


___
Python-Dev mailing list
[email protected]
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

2012-09-29 Thread Stefan Krah 
Antoine Pitrou  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
[email protected]
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

2012-09-29 Thread Georg Brandl 

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
[email protected]
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

2012-09-29 Thread Amit Saha 
On Sat, Sep 29, 2012 at 10:18 PM, Georg Brandl  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
[email protected]
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

2012-09-29 Thread Amit Saha 
On Sat, Sep 29, 2012 at 10:37 PM, Dave Angel  wrote:
> On 09/29/2012 08:23 AM, Amit Saha wrote:
>> On Sat, Sep 29, 2012 at 10:18 PM, Georg Brandl  wrote:
>>> 
>>>
>>> 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
[email protected]
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

2012-09-29 Thread Paul Moore 
On 29 September 2012 10:17, Stefan Krah  wrote:
> Tim Delaney  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
[email protected]
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

2012-09-29 Thread Eli Bendersky 
On Sat, Sep 29, 2012 at 5:18 AM, Georg Brandl  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
[email protected]
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

2012-09-29 Thread Paul Moore 
On 29 September 2012 14:24, Eli Bendersky  wrote:
> On Sat, Sep 29, 2012 at 5:18 AM, Georg Brandl  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
[email protected]
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

2012-09-29 Thread Guido van Rossum 
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  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
> [email protected]
> 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
[email protected]
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

2012-09-29 Thread Dave Angel 
On 09/29/2012 08:23 AM, Amit Saha wrote:
> On Sat, Sep 29, 2012 at 10:18 PM, Georg Brandl  wrote:
>> 
>>
>> 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
[email protected]
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

2012-09-29 Thread python 
> Agreed - this is a really nice release, thanks to all who put it together.

+1

Thank you!
Malcolm
___
Python-Dev mailing list
[email protected]
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

2012-09-29 Thread Antoine Pitrou 

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  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
[email protected]
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

2012-09-29 Thread Glenn Linderman 

On Sat, Sep 29, 2012 at 5:18 AM, Georg Brandl  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 
 
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  
section of this document; it will only affect code that currently 
manipulates import or calls it programmatically.
___
Python-Dev mailing list
[email protected]
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-09-29 Thread Benjamin Peterson 
2012/9/28 Ben Wolfson :
> 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
[email protected]
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-09-29 Thread Ben Wolfson 
On Sat, Sep 29, 2012 at 10:59 AM, Benjamin Peterson  wrote:
> 2012/9/28 Ben Wolfson :
>> 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
[email protected]
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

2012-09-29 Thread Brett Cannon 
On Sat, Sep 29, 2012 at 9:07 AM, Paul Moore  wrote:

> On 29 September 2012 10:17, Stefan Krah  wrote:
> > Tim Delaney  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
[email protected]
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

2012-09-29 Thread R. David Murray 
On Sat, 29 Sep 2012 10:46:37 -0700, Glenn Linderman  
wrote:
> On Sat, Sep 29, 2012 at 5:18 AM, Georg Brandl  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 
> >  
> > 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  
> 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
[email protected]
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

2012-09-29 Thread Guido van Rossum 
On Sat, Sep 29, 2012 at 11:26 AM, Brett Cannon  wrote:
>
>
> On Sat, Sep 29, 2012 at 9:07 AM, Paul Moore  wrote:
>>
>> On 29 September 2012 10:17, Stefan Krah  wrote:
>> > Tim Delaney  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
[email protected]
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

2012-09-29 Thread Chris Angelico 
On Sun, Sep 30, 2012 at 4:26 AM, Brett Cannon  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
[email protected]
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-09-29 Thread Eric V. Smith 
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  wrote:

> On Sat, Sep 29, 2012 at 10:59 AM, Benjamin Peterson  
> wrote:
>> 2012/9/28 Ben Wolfson :
>>> 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
> [email protected]
> 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
[email protected]
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?

2012-09-29 Thread Gregory P. Smith 
-cc: python-dev
+cc: python-ideas

On Sat, Sep 29, 2012 at 11:39 AM, Chris Angelico  wrote:

> On Sun, Sep 30, 2012 at 4:26 AM, Brett Cannon  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
[email protected]
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

2012-09-29 Thread Tim Delaney 
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
[email protected]
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

2012-09-29 Thread Tim Delaney 
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
[email protected]
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

2012-09-29 Thread Ned Deily 
In article 
,
 Tim Delaney  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,
 [email protected]

___
Python-Dev mailing list
[email protected]
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

2012-09-29 Thread Brett Cannon 
On Sep 29, 2012 2:38 PM, "Guido van Rossum"  wrote:
>
> On Sat, Sep 29, 2012 at 11:26 AM, Brett Cannon  wrote:
> >
> >
> > On Sat, Sep 29, 2012 at 9:07 AM, Paul Moore  wrote:
> >>
> >> On 29 September 2012 10:17, Stefan Krah  wrote:
> >> > Tim Delaney  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
[email protected]
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)"???

2012-09-29 Thread Jan Kaliszewski 

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
[email protected]
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)"???

2012-09-29 Thread MRAB 

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
[email protected]
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)"???

2012-09-29 Thread Steven D'Aprano 

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
[email protected]
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

2012-09-29 Thread R. David Murray 
On Sun, 30 Sep 2012 08:01:00 +1000, Tim Delaney  
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
[email protected]
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

2012-09-29 Thread Chris Jerdonek 
On Sat, Sep 29, 2012 at 10:09 PM, R. David Murray  wrote:
> On Sun, 30 Sep 2012 08:01:00 +1000, Tim Delaney  
> 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
[email protected]
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)"???

2012-09-29 Thread Terry Reedy 

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
[email protected]
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

2012-09-29 Thread Terry Reedy 

On 9/29/2012 2:38 PM, Guido van Rossum 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.


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.


It is also one of, if not *the* oldest application 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?)


I think not. The money community does not use complexes that I know of, 
and complex decimals would not be very useful without a complex decimal 
module (and 3rd party modules). Even the complex float operations and 
cmath library could use work to touch up and test corner cases.


I can imagine giving IDLE a calulator mode. If Python itself had a 
startup switch, Idle could just restart the remote process. If a new 
suffix is used, Idle could add the suffix as literal numbers are entered.


--
Terry Jan Reedy

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com