>> I don't pretend to understand the reasons for all of this,
>> but if it is possible to use the same integer object whenever
>> it is referenced, then why should there be a limit on range?
>
> Preallocating all the 4 billion 4-byte ints would overfill the memory of
> most machines ;-)
Sure, I
Terry Reedy wrote:
> "Georg Brandl" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> tobiah wrote:
>>> Suppose I fill an list with 100 million random integers in the range
>>> of 1 - 65535. Wouldn't I save much memory if all of the ocurrances
>>> of '12345' pointed to the same int
"Georg Brandl" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> tobiah wrote:
>> Suppose I fill an list with 100 million random integers in the range
>> of 1 - 65535. Wouldn't I save much memory if all of the ocurrances
>> of '12345' pointed to the same integer object? Why should m
"tobiah" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> wesley chun wrote:
>>> "Terry Reedy" <[EMAIL PROTECTED]> wrote:
>>> > as a side note, the ints that are cached (for current versions of
>>> > Python) are in range(-1, 100)... is this documented somewhere?
>>> Not true for at l
tobiah wrote:
> Simon Brunning wrote:
>
>>On 9/27/06, tobiah <[EMAIL PROTECTED]> wrote:
>>
>>>Suppose I fill an list with 100 million random integers in the range
>>>of 1 - 65535. Wouldn't I save much memory if all of the ocurrances
>>>of '12345' pointed to the same integer object? Why should mo
Georg Brandl <[EMAIL PROTECTED]> wrote:
>> Suppose I fill an list with 100 million random integers in the range
>> of 1 - 65535. Wouldn't I save much memory if all of the ocurrances
>> of '12345' pointed to the same integer object? Why should more be
>> made, when they all do the same thing, and
tobiah wrote:
>>> Suppose I fill an list with 100 million random integers in the range
>>> of 1 - 65535. Wouldn't I save much memory if all of the ocurrances
>>> of '12345' pointed to the same integer object? Why should more be made,
>>> when they all do the same thing, and are not subject to cha
>> Suppose I fill an list with 100 million random integers in the range
>> of 1 - 65535. Wouldn't I save much memory if all of the ocurrances
>> of '12345' pointed to the same integer object? Why should more be made,
>> when they all do the same thing, and are not subject to change?
>
> Because
Simon Brunning wrote:
> On 9/27/06, tobiah <[EMAIL PROTECTED]> wrote:
>> Suppose I fill an list with 100 million random integers in the range
>> of 1 - 65535. Wouldn't I save much memory if all of the ocurrances
>> of '12345' pointed to the same integer object? Why should more be made,
>> when th
tobiah wrote:
> wesley chun wrote:
>>> "Terry Reedy" <[EMAIL PROTECTED]> wrote:
>>> > as a side note, the ints that are cached (for current versions of
>>> > Python) are in range(-1, 100)... is this documented somewhere?
>>> Not true for at least 2.4 and 2.5. The cached range has expanded
>>
>> o
On 9/27/06, tobiah <[EMAIL PROTECTED]> wrote:
> Suppose I fill an list with 100 million random integers in the range
> of 1 - 65535. Wouldn't I save much memory if all of the ocurrances
> of '12345' pointed to the same integer object? Why should more be made,
> when they all do the same thing, an
wesley chun wrote:
>> "Terry Reedy" <[EMAIL PROTECTED]> wrote:
>> > as a side note, the ints that are cached (for current versions of
>> > Python) are in range(-1, 100)... is this documented somewhere?
>> Not true for at least 2.4 and 2.5. The cached range has expanded
>
> oops, apologies to all.
> "Terry Reedy" <[EMAIL PROTECTED]> wrote:
> > as a side note, the ints that are cached (for current versions of
> > Python) are in range(-1, 100)... is this documented somewhere?
> Not true for at least 2.4 and 2.5. The cached range has expanded
oops, apologies to all... it really *is* subject t
"wesley chun" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> as a side note, the ints that are cached (for current versions of
> Python) are in range(-1, 100)... is this documented somewhere?
Not true for at least 2.4 and 2.5. The cached range has expanded
> i know it's subject
Wesley> as a side note, the ints that are cached (for current versions
Wesley> of Python) are in range(-1, 100)... is this documented
Wesley> somewhere?
Other than the code, probably not. Since it's an implementation
optimization, I see no particular reason that it should be document
as a side note, the ints that are cached (for current versions of
Python) are in range(-1, 100)... is this documented somewhere? i know
it's subject to change. and as already mentioned, you probably
wouldn't use "is" this way in real code... i know you are just
reinforcing your learning of the dif
Antoon Pardon wrote:
>
> I find this a bit oddly worded. Now the "may always reuse" phrase
> suggests this is not an obligation and I can certainly understand
> that in the case of integers. But when you enumerate examples you
> include None and Booleans, creating the suggestion these don't
> have
On 2006-09-26, John Roth <[EMAIL PROTECTED]> wrote:
>
> Antoon Pardon wrote:
>>
>> I find this a bit oddly worded. Now the "may always reuse" phrase
>> suggests this is not an obligation and I can certainly understand
>> that in the case of integers. But when you enumerate examples you
>> include N
"codefire" <[EMAIL PROTECTED]> writes:
> I was just trying to check if objects were the same (object), didn't
> know Integers were a special case.
They're not. The Python runtime environment can do whatever it likes
underneath the hood; the language gives no promises about any
relationship betwee
Thanks for that Fredrik, that's clear. That's actually a pretty nice
feature as it's nicely optimised.
>>> a = 10
>>> c = 10
>>> a is c
True
>>> c = c +1
>>> a is c
False
>>>
Cheers,
Tony
--
http://mail.python.org/mailman/listinfo/python-list
Haha!
OK thanks guys.
I was just trying to check if objects were the same (object), didn't
know Integers were a special case.
Thanks,
Tony
--
http://mail.python.org/mailman/listinfo/python-list
On 2006-09-26, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> codefire wrote:
>
>> I was just trying to check if objects were the same (object), didn't
>> know Integers were a special case.
>
> they're not, really; "is" works the same way for all objects.
>
> when you ask for a new immutable object, a
codefire a écrit :
> Haha!
>
> OK thanks guys.
>
> I was just trying to check if objects were the same (object), didn't
> know Integers were a special case.
They are not a special case so much. It's just that "is" is extremly
unreliable unless you're the one who created the objects. In the case
codefire wrote:
> I was just trying to check if objects were the same (object), didn't
> know Integers were a special case.
they're not, really; "is" works the same way for all objects.
when you ask for a new immutable object, a Python implementation may
always reuse an existing object, if it w
codefire a écrit :
> I thought the 'is' operator was used to identify identical objects,
> whereas the '==' operator checked equality. Well, I got a surprise
> here:
>
> IDLE 1.1.3
a = 10
b = a
a is b
> True
a == b
> True
c = 10
a == c
> True
a is c
> True
>
> I
codefire wrote:
> I thought the 'is' operator was used to identify identical objects,
> whereas the '==' operator checked equality. Well, I got a surprise
> here:
>
> IDLE 1.1.3
a = 10
b = a
a is b
> True
a == b
> True
c = 10
a == c
> True
a is c
> True
>
I thought the 'is' operator was used to identify identical objects,
whereas the '==' operator checked equality. Well, I got a surprise
here:
IDLE 1.1.3
>>> a = 10
>>> b = a
>>> a is b
True
>>> a == b
True
>>> c = 10
>>> a == c
True
>>> a is c
True
>>>
I was NOT expecting the last statement to ret
27 matches
Mail list logo
