half doing a = foo(a). Also, it's done so that you
don't need to special case integer literals: they are (fixed) names to the same
immutable instances and nobody can modify the value of 13 or any other literal.
But why not have mutable numbers also in the language. A type which
would behave
Suresh Jeevanandam a écrit :
# I am new to python.
In python all numbers are immutable. This means there is one object ( a
region in the memory ) created every time we do an numeric operation. I
hope there should have been some good reasons why it was designed this way.
The memory
fraca7 wrote:
Suresh Jeevanandam a écrit :
# I am new to python.
In python all numbers are immutable. This means there is one object ( a
region in the memory ) created every time we do an numeric operation. I
hope there should have been some good reasons why it was designed this way.
fraca7 wrote:
Suresh Jeevanandam a écrit :
# I am new to python.
In python all numbers are immutable. This means there is one object ( a
region in the memory ) created every time we do an numeric operation. I
hope there should have been some good reasons why it was designed this way.
Steve Holden wrote:
The memory allocation for integers is optimized. 'Small' integers
(between -5 and 100 IIRC) are allocated once and reused. The memory for
larger integers is allocated once and reused whenever possible, so the
malloc() overhead is negligible.
The first bit's right,
Steve Holden wrote:
The memory allocation for integers is optimized. 'Small' integers
(between -5 and 100 IIRC) are allocated once and reused. The memory for
larger integers is allocated once and reused whenever possible, so the
malloc() overhead is negligible.
The first bit's right,
some good reasons why it was designed this way.
But why not have mutable numbers also in the language. A type which
would behave as follows:
a = MutableInt(12)
a = [12]
b = a
Now both a and b should refer to the same memory location. Any change in
the object should get reflected in all
Steve Holden a écrit :
[Thinks: or maybe fraca7 just meant that integers will be garbage
collected when there are no more references to them].
Actually I meant that the memory is reused, but the same integer won't
always have the same address.
I guess that in your example, the '121' is
fraca7 a écrit :
Steve Holden a écrit :
[Thinks: or maybe fraca7 just meant that integers will be garbage
collected when there are no more references to them].
Actually I meant that the memory is reused, but the same integer won't
always have the same address.
And of course this means
Steve Holden wrote:
fraca7 wrote:
The memory allocation for integers is optimized. 'Small' integers
(between -5 and 100 IIRC) are allocated once and reused. The memory
for larger integers is allocated once and reused whenever possible, so
the malloc() overhead is negligible.
The
Rocco def f():
Rocco a = 12100
Rocco b = 12100
Rocco c = 121*100
Rocco print a is b
Rocco print a is c
That the object with value 12100 is referenced by both a and b is a side
effect of byte code compilation by CPython not an inherent property of
Suresh Jeevanandam wrote:
# I am new to python.
[...]
In any application most of the operation is numerical. So, i think, we
should get a good speed advantage with the availability of mutable
numbers. What do you think ?
If you are new to Python, I think you should try to learn how to
use
# I am new to python.
In python all numbers are immutable. This means there is one object ( a
region in the memory ) created every time we do an numeric operation. I
hope there should have been some good reasons why it was designed this way.
But why not have mutable numbers also
Suresh Jeevanandam wrote:
But why not have mutable numbers also in the language.
The short answer I'd give is probably that this is so easy to do with a
user-defined class that it's never been all that pressing.
In any application most of the operation is numerical. So, i think, we
should
14 matches
Mail list logo
