int() 24 times slower then long() in Python 2.3

[paolo veronelli]

On Wed, 14 Jul 2004 11:08:16 +0100, James Henderson 
<james at logicalprogression.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wednesday 14 July 2004 8:32 am, paolo veronelli wrote:
>> On 13 Jul 2004 14:34:25 -0700, Paul Rubin 
>> <"http://phr.cx"@NOSPAM.invalid>
>>
>> wrote:
>> > "Nick Smallbone" <nick at nick8325.freeserve.co.uk> writes:
>> >> > IMO the speed at which a bunch of invalid conversions are
>> >> > executed means nothing at all. Could you come up with an example
>> >> > that show the same symptoms in a meaningful context?
>> >>
>> >> What do you mean? bbbbaaaa is a hex number.
>> >>
>> >> >>> int('bbbbaaaa', 16)
>> >>
>> >> 3149638314L
>> >
>> > It's not an int.  It has to attempt to convert to int, trap the error
>> > and recover from it, and then convert to a long.
>>
>> I don't undersand the meaning of int()
>> If I want an int() (two bytes?) I want two bytes.It should truncate.If 
>> the
>> result is the same with long() a part from the warning
>> I think int() is unmeaningfull.Transparency is away from warnings.
>> This python is saying I used the wrong function and there at least two
>> cases:
>> 	I have wrong results.
>> 	He is doing my businness.
>>
>> IMHO I want wrong results.
>>

>
> I think you should look at PEP 237 "Unifying Long Integers and Integers" 
> - it
> may even reassure you.  As Peter Hansen has already hinted in reply to
> another of your messages, Python is in the process of unifying longs and
> ints.
>
> It used to be that calling int() on a big number gave an exception - 
> perhaps a
> more Pythonic version of your requested giving the wrong result - and now
> that it doesn't I suppose there is a sense in which the current 
> distinction
> between ints and longs is "unmeaningful" from the user's point of view 
> (it's
> not meaningless under the hood of course).  According to the PEP the 
> decision
> to keep two types was that it:
>
>     is far easier to implement, is backwards
>     compatible at the C API level, and in addition can be implemented
>     partially as a transitional measure.
>
> Perhaps you thing that ints and longs should not be unified but I won't 
> start
> arguing till you come out and say it. :)
>
> James
I don't want to change any way the base of PEP 237,but this kind of 
performance
flaw  is a problem and it's possible to be the first of  a long list.
It's good to know, always ,why we pay a price.Better an Error then a ghost 
warning,which
is itself the cause of the flaw.
Python is fast ,this is why I use it.Anyone has a different goal in using 
it.

	Regards    Paolino




-- 
....lotta dura  per la verdura