Steven D'Aprano st...@remove-this-cybersource.com.au wrote:
On Sat, 29 Aug 2009 11:11:43 -0700, zaur wrote:
I thought that int as object will stay the same object after += but with
another integer value. My intuition said me that int object which
represent integer value should behave this
Carl Banks pavlovevide...@gmail.com (CB) wrote:
CB On Sep 1, 10:40 am, Piet van Oostrum p...@cs.uu.nl wrote:
Numbers are immutable by nature (math). The number 3.14 remains 3.14
whatever you try to do with it. What you call an immutable number is in
fact a container that contains a number.
On Mon, 31 Aug 2009 10:21:22 -0700, zaur wrote:
As a result of this debate is not whether we should conclude that there
should be two types of integers in python: 1) immutable numbers, which
behave as constant value; 2) mutable numbers, which behave as variable
value?
What can you do with
On 1 сен, 03:31, Steven D'Aprano st...@remove-this-
cybersource.com.au wrote:
On Mon, 31 Aug 2009 10:21:22 -0700, zaur wrote:
As a result of this debate is not whether we should conclude that there
should be two types of integers in python: 1) immutable numbers, which
behave as constant
zaur szp...@gmail.com (z) wrote:
z On 29 авг, 16:45, zaur szp...@gmail.com wrote:
Python 2.6.2 (r262:71600, Apr 16 2009, 09:17:39)
[GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin
Type copyright, credits or license() for more information. a=1
x=[a]
id(a)==id(x[0])
True
a+=1
a
On Tue, 01 Sep 2009 07:04:09 -0700, zaur wrote:
On 1 сен, 03:31, Steven D'Aprano st...@remove-this- cybersource.com.au
wrote:
On Mon, 31 Aug 2009 10:21:22 -0700, zaur wrote:
As a result of this debate is not whether we should conclude that
there should be two types of integers in python:
On Sep 1, 10:40 am, Piet van Oostrum p...@cs.uu.nl wrote:
zaur szp...@gmail.com (z) wrote:
z On 29 авг, 16:45, zaur szp...@gmail.com wrote:
Python 2.6.2 (r262:71600, Apr 16 2009, 09:17:39)
[GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin
Type copyright, credits or license() for
Steven D'Aprano wrote:
I'm asking what *problem* you are trying to solve with mutable numbers,
where immutable numbers are not satisfactory. The only answer I can
imagine is that you're worried about the overhead of creating new integer
objects instead of just flipping a few bits in an
On Tue, 01 Sep 2009 16:43:06 -0700, Carl Banks wrote:
Numbers are immutable by nature (math). The number 3.14 remains 3.14
whatever you try to do with it. What you call an immutable number is in
fact a container that contains a number.
I wouldn't agree with that terminology or logic.
Derek Martin c...@pizzashack.org (DM) wrote:
DM On Sun, Aug 30, 2009 at 03:42:06AM -0700, Paul McGuire wrote:
Is it any odder that 3 is an object than that the string literal
Hello, World! is an object?
DM Yes. Because 3 is a fundamental bit of data that the hardware knows
DM how to deal
On Aug 31, 10:21 am, zaur szp...@gmail.com wrote:
On 29 авг, 16:45, zaur szp...@gmail.com wrote:
Python 2.6.2 (r262:71600, Apr 16 2009, 09:17:39)
[GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin
Type copyright, credits or license() for more information. a=1
x=[a]
On 29 авг, 16:45, zaur szp...@gmail.com wrote:
Python 2.6.2 (r262:71600, Apr 16 2009, 09:17:39)
[GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin
Type copyright, credits or license() for more information. a=1
x=[a]
id(a)==id(x[0])
True
a+=1
a
2
x[0]
1
I thought that +=
On Sat, Aug 29, 2009 at 07:03:23PM +, Steven D'Aprano wrote:
On Sat, 29 Aug 2009 11:11:43 -0700, zaur wrote:
I thought that int as object will stay the same object after += but with
another integer value. My intuition said me that int object which
represent integer value should behave
On Aug 29, 8:03 pm, Steven D'Aprano st...@remove-this-
cybersource.com.au wrote:
On Sat, 29 Aug 2009 11:11:43 -0700, zaur wrote:
I thought that int as object will stay the same object after += but with
another integer value. My intuition said me that int object which
represent integer value
On Sun, 30 Aug 2009 02:33:05 -0500, Derek Martin wrote:
On Sat, Aug 29, 2009 at 07:03:23PM +, Steven D'Aprano wrote:
On Sat, 29 Aug 2009 11:11:43 -0700, zaur wrote:
I thought that int as object will stay the same object after += but
with another integer value. My intuition said me
On Aug 30, 2:33 am, Derek Martin c...@pizzashack.org wrote:
THAT is why Python's behavior with regard to numerical objects is
not intuitive, and frankly bizzare to me, and I dare say to others who
find it so.
Yes, that's right. BIZZARE.
Can't we all just get along?
I think the question
On Sun, 30 Aug 2009 01:01:37 -0700, Mark Dickinson wrote:
On Aug 29, 8:03 pm, Steven D'Aprano st...@remove-this-
cybersource.com.au wrote:
On Sat, 29 Aug 2009 11:11:43 -0700, zaur wrote:
I thought that int as object will stay the same object after += but
with another integer value. My
On Aug 30, 5:42 am, Paul McGuire pt...@austin.rr.com wrote:
Python binds values to names. Always. In Python, = is not and never
could be a class operator. In Python, any expression of LHS = RHS,
LHS is always a name, and in this statement it is being bound to some
object found by evaluating
On Sun, 2009-08-30 at 10:44 +, Steven D'Aprano wrote:
It also follows from the idea that there is one abstract entity which
English speakers call three and write as 3. There's not two
identical
entities with value 3, or four, or a million of them, only one.
That's not true. There are
On Aug 30, 3:34 am, Steven D'Aprano st...@remove-this-
cybersource.com.au wrote:
On Sun, 30 Aug 2009 02:33:05 -0500, Derek Martin wrote:
On Sat, Aug 29, 2009 at 07:03:23PM +, Steven D'Aprano wrote:
On Sat, 29 Aug 2009 11:11:43 -0700, zaur wrote:
I thought that int as object will stay
On Aug 30, 12:33 am, Derek Martin c...@pizzashack.org wrote:
[snip rant]
THAT is why Python's behavior with regard to numerical objects is
not intuitive, and frankly bizzare to me, and I dare say to others who
find it so.
Yes, that's right. BIZZARE.
You mean it's different from how you
On 29 авг, 23:03, Steven D'Aprano st...@remove-this-
cybersource.com.au wrote:
On Sat, 29 Aug 2009 11:11:43 -0700, zaur wrote:
I thought that int as object will stay the same object after += but with
another integer value. My intuition said me that int object which
represent integer value
On Sun, 2009-08-30 at 04:49 -0700, Carl Banks wrote:
It's pretty common for people coming from name is a location in
memory languages to have this conception of integers as an
intermediate stage of learning Python's object system. Even once
they've understood everything is an object and names
On 30 авг, 15:49, Carl Banks pavlovevide...@gmail.com wrote:
I think they (Derek and zaur) expect integer objects to be mutable.
It's pretty common for people coming from name is a location in
memory languages to have this conception of integers as an
intermediate stage of learning Python's
On Sun, Aug 30, 2009 at 10:34:17AM +, Steven D'Aprano wrote:
He's saying that instead of thinking the integer value of 3 itself being
the object, he expected Python's object model would behave as though the
entity m is the object, and that object exists to contain an integer
value.
On Sun, 30 Aug 2009 17:37:49 +0100, zaur szp...@gmail.com wrote:
On 30 авг, 15:49, Carl Banks pavlovevide...@gmail.com wrote:
I think they (Derek and zaur) expect integer objects to be mutable.
It's pretty common for people coming from name is a location in
memory languages to have this
On Sun, Aug 30, 2009 at 03:42:06AM -0700, Paul McGuire wrote:
Python binds values to names. Always.
No, actually, it doesn't. It binds *objects* to names. This
distinction is subtle, but important, as it is the crux of why this is
confusing to people. If Python is to say that objects have
On Sun, Aug 30, 2009 at 04:26:54AM -0700, Carl Banks wrote:
On Aug 30, 12:33 am, Derek Martin c...@pizzashack.org wrote:
[snip rant]
I was not ranting. I was explaining a perspective.
THAT is why Python's behavior with regard to numerical objects is
not intuitive, and frankly bizzare to
Derek Martin wrote:
If Python is to say that objects have values,
then the object can not *be* the value that it has, because that is a
paradoxical self-reference. It's an object, not a value.
But does it say that objects have values? I don't see where you
get this idea. Consider
On Sun, Aug 30, 2009 at 03:52:36AM -0700, Paul McGuire wrote:
It is surprising how many times we
think things are intuitive when we really mean they are familiar.
Of course, just as I was typing my response, Steve D'Aprano beat me to
the punch.
Intuition means The power or faculty of
On Sun, Aug 30, 2009 at 05:43:42PM +, OKB (not okblacke) wrote:
Derek Martin wrote:
If Python is to say that objects have values,
then the object can not *be* the value that it has, because that is a
paradoxical self-reference. It's an object, not a value.
But does it say
On Sun, 30 Aug 2009 12:04:45 -0500, Derek Martin wrote:
On Sun, Aug 30, 2009 at 03:42:06AM -0700, Paul McGuire wrote:
Python binds values to names. Always.
No, actually, it doesn't. It binds *objects* to names. This
distinction is subtle, but important, as it is the crux of why this is
On Aug 30, 10:27 am, Derek Martin c...@pizzashack.org wrote:
On Sun, Aug 30, 2009 at 03:52:36AM -0700, Paul McGuire wrote:
It is surprising how many times we
think things are intuitive when we really mean they are familiar.
Of course, just as I was typing my response, Steve D'Aprano beat
Python 2.6.2 (r262:71600, Apr 16 2009, 09:17:39)
[GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin
Type copyright, credits or license() for more information.
a=1
x=[a]
id(a)==id(x[0])
True
a+=1
a
2
x[0]
1
I thought that += should only change the value of the int object. But
+= create
On Aug 29, 7:45 am, zaur szp...@gmail.com wrote:
Python 2.6.2 (r262:71600, Apr 16 2009, 09:17:39)
[GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin
Type copyright, credits or license() for more information. a=1
x=[a]
id(a)==id(x[0])
True
a+=1
a
2
x[0]
1
I thought that +=
zaur szp...@gmail.com wrote:
Python 2.6.2 (r262:71600, Apr 16 2009, 09:17:39)
[GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin
Type copyright, credits or license() for more information.
a=1
x=[a]
id(a)==id(x[0])
True
a+=1
a
2
x[0]
1
I thought that += should only change the value of
zaur wrote:
Python 2.6.2 (r262:71600, Apr 16 2009, 09:17:39)
[GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin
Type copyright, credits or license() for more information.
a=1
x=[a]
id(a)==id(x[0])
True
a+=1
a
2
x[0]
1
I thought that += should only
Paul McGuire pt...@austin.rr.com wrote:
What exactly are you trying to do?
I think, he wants to kind of dereference the list element. So that he
can write
a += 1
instead of
long_name_of_a_list_which_contains_data[mnemonic_pointer_name] += 1
Regards,
Günther
--
On 29 авг, 20:25, Günther Dietrich gd_use...@spamfence.net wrote:
Paul McGuire pt...@austin.rr.com wrote:
What exactly are you trying to do?
I think, he wants to kind of dereference the list element. So that he
can write
a += 1
instead of
On Sat, 29 Aug 2009 11:11:43 -0700, zaur wrote:
I thought that int as object will stay the same object after += but with
another integer value. My intuition said me that int object which
represent integer value should behave this way.
If it did, then you would have this behaviour:
n = 3
On Aug 29, 8:08 am, Paul McGuire pt...@austin.rr.com wrote:
On Aug 29, 7:45 am, zaur szp...@gmail.com wrote:
Python 2.6.2 (r262:71600, Apr 16 2009, 09:17:39)
[GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin
Type copyright, credits or license() for more information. a=1
x=[a]
41 matches
Mail list logo
