Performance of int/long in Python 3

[Mark Lawrence]

On 02/04/2013 11:58, Steve Simmons wrote:
>
> On 02/04/2013 10:43, Mark Lawrence wrote:
>> On 02/04/2013 10:24, jmfauth wrote:
>>> On 2 avr, 10:35, Steven D'Aprano <steve
>>> +comp.lang.pyt... at pearwood.info> wrote:
>>>> On Tue, 02 Apr 2013 19:03:17 +1100, Chris Angelico wrote:
>>>>
>>>> So what? Who cares if it takes 0.00002 second to insert a character
>>>> instead of 0.00001 second? That's still a hundred times faster than you
>>>> can type.
>>>>
>>> ---------
>>>
>>> This not the problem. The interesting point is that they
>>> are good and "less good" Unicode implementations.
>>>
>>> jmf
>>>
>>
>> The interesting point is that the Python 3.3 unicode implementation is
>> correct, that of most other languages is buggy. Or have I fallen
>> victim to the vicious propaganda of the various Pythonistas who
>> frequent this list?
>>
> Mark,
>
> Thanks for asking this question.
>
> It seems to me that jmf *might* be moving towards a vindicated
> position.  There is some interest now in duplicating, understanding and
> (hopefully!) extending his test results, which can only be a Good Thing
> - whatever the outcome and wherever the facepalm might land.
>

The position that is already documented in PEP393, how so?

> However, as you rightly point out, there is only value in following this
> through if the functionality is (at least near) 100% correct. I am sure
> there are some that will disagree but in most cases, functionality is
> the primary requirement and poor performance can be managed initially
> and fixed in due time.

I've already raised an issue about performance and Neil Hodgson has 
raised a new one.  To balance this out perhaps we should have counter 
issues asking for the amount of memory being used to be increased to old 
levels and the earlier buggier behaviour of Python to be reintroduced? 
Swings and roundabouts?

>
> Steve


-- 
If you're using GoogleCrap™ please read this 
http://wiki.python.org/moin/GoogleGroupsPython.

Mark Lawrence