Steven D'Aprano [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
On Wed, 17 Oct 2007 13:41:06 +0200, Hrvoje Niksic wrote:
The current implementation of += uses __add__ for addition and __iadd__
for addition that may or may not be in-place. I'd like to know the
rationale for that
On Oct 10, 8:23 am, Diez B. Roggisch [EMAIL PROTECTED] wrote:
However, it is not true that += always leads to a rebinding of a to the
result of the operation +. The + operator for lists creates a new list.
+= for lists does an in-place modification:
It still is true.
a += b
rebinds a.
On Wed, 17 Oct 2007 00:33:59 -0700, paul.melis wrote:
On Oct 10, 8:23 am, Diez B. Roggisch [EMAIL PROTECTED] wrote:
However, it is not true that += always leads to a rebinding of a to the
result of the operation +. The + operator for lists creates a new list.
+= for lists does an in-place
[EMAIL PROTECTED] wrote:
On Oct 10, 8:23 am, Diez B. Roggisch [EMAIL PROTECTED] wrote:
snip
rebinds a. Period. Which is the _essential_ thing in my post, because
this rebinding semantics are what confused the OP.
Doesn't this depend on wether a supports __iadd__ or not? Section
3.4.7 of
On Oct 17, 10:00 am, Duncan Booth [EMAIL PROTECTED]
wrote:
[EMAIL PROTECTED] wrote:
On Oct 10, 8:23 am, Diez B. Roggisch [EMAIL PROTECTED] wrote:
snip
rebinds a. Period. Which is the _essential_ thing in my post, because
this rebinding semantics are what confused the OP.
Doesn't this
[EMAIL PROTECTED] wrote:
Curious, do you have the relevant section in the docs that describes
this behaviour?
Yes, but mostly by implication. In section 3.4.7 of the docs, the sentence
before the one you quoted says:
These methods should attempt to do the operation in-place (modifying
On Oct 17, 11:08 am, Duncan Booth [EMAIL PROTECTED]
wrote:
[EMAIL PROTECTED] wrote:
Curious, do you have the relevant section in the docs that describes
this behaviour?
Yes, but mostly by implication. In section 3.4.7 of the docs, the sentence
before the one you quoted says:
These
[EMAIL PROTECTED] writes:
Right, the paragraph is actually pretty clear after a second
reading. I find it surprising nonetheless, as it's easy to forget
to return a result when you're implementing a method that does an
in-place operation, like __iadd__:
I've recently been bitten by that,
Hrvoje Niksic [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] writes:
Right, the paragraph is actually pretty clear after a second
reading. I find it surprising nonetheless, as it's easy to forget
to return a result when you're implementing a method that does an
in-place operation, like
Duncan Booth [EMAIL PROTECTED] writes:
Hrvoje Niksic [EMAIL PROTECTED] wrote:
I've recently been bitten by [rebinding the var to what __iadd__
returns], and I don't understand the reasoning behind __iadd__'s
design. I mean, what is the point of an *in-place* add operation
(and others) if
On Wed, 17 Oct 2007 13:41:06 +0200, Hrvoje Niksic wrote:
Duncan Booth [EMAIL PROTECTED] writes:
Hrvoje Niksic [EMAIL PROTECTED] wrote:
I've recently been bitten by [rebinding the var to what __iadd__
returns], and I don't understand the reasoning behind __iadd__'s
design. I mean, what is
On Wed, 17 Oct 2007 13:41:06 +0200, Hrvoje Niksic wrote:
The current implementation of += uses __add__ for addition and __iadd__
for addition that may or may not be in-place. I'd like to know the
rationale for that design.
Everything you need is in the PEP:
Hrvoje Niksic [EMAIL PROTECTED] wrote:
The current implementation of += uses __add__ for addition and
__iadd__ for addition that may or may not be in-place. I'd like to
know the rationale for that design.
Apart from the obvious short answer of being consistent (so you don't
have to
Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote:
Simply not to introduce special cases I guess. If you write ``x.a +=
b`` then `x.a` will be rebound whether an `a.__iadd__()` exists or
not. Otherwise one would get interesting subtle differences with
properties for example. If `x.a` is a
On Oct 17, 2:39 pm, Duncan Booth [EMAIL PROTECTED] wrote:
Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote:
Simply not to introduce special cases I guess. If you write ``x.a +=
b`` then `x.a` will be rebound whether an `a.__iadd__()` exists or
not. Otherwise one would get interesting
On Oct 17, 3:20 pm, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote:
On Wed, 17 Oct 2007 05:57:50 -0700, Paul Melis wrote:
On Oct 17, 2:39 pm, Duncan Booth [EMAIL PROTECTED] wrote:
class C(object):
def setx(self, value):
if len(value)2:
On Oct 17, 3:41 pm, Paul Melis [EMAIL PROTECTED] wrote:
On Oct 17, 3:20 pm, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote:
On Wed, 17 Oct 2007 05:57:50 -0700, Paul Melis wrote:
On Oct 17, 2:39 pm, Duncan Booth [EMAIL PROTECTED] wrote:
class C(object):
def setx(self,
On Wed, 17 Oct 2007 05:57:50 -0700, Paul Melis wrote:
On Oct 17, 2:39 pm, Duncan Booth [EMAIL PROTECTED] wrote:
class C(object):
def setx(self, value):
if len(value)2:
raise ValueError
self._x = value
def getx(self):
Marc 'BlackJack' Rintsch [EMAIL PROTECTED] writes:
Simply not to introduce special cases I guess. If you write ``x.a
+= b`` then `x.a` will be rebound whether an `a.__iadd__()` exists
or not. Otherwise one would get interesting subtle differences with
properties for example. If `x.a` is a
Duncan Booth [EMAIL PROTECTED] writes:
Hrvoje Niksic [EMAIL PROTECTED] wrote:
The current implementation of += uses __add__ for addition and
__iadd__ for addition that may or may not be in-place. I'd like to
know the rationale for that design.
Apart from the obvious short answer of
Yes, it is.
I'm afraid not.
As I admitted in my reply to Marc, I overstated my case by saying that L
isn't rebound at all. Of course it is rebound, but to itself.
However, it is not true that += always leads to a rebinding of a to the
result of the operation +. The + operator for
Diez B. Roggisch schrieb:
Yes, it is.
I'm afraid not.
As I admitted in my reply to Marc, I overstated my case by saying that
L isn't rebound at all. Of course it is rebound, but to itself.
However, it is not true that += always leads to a rebinding of a to
the result of the operation +.
Steven D'Aprano írta:
On Tue, 09 Oct 2007 21:25:38 +0200, Laszlo Nagy wrote:
a = 1
a+= 1 # The compiler will probably optimize this and the Python bytecode
interpreter will not rebind 'a' here, just increment the integer in
memory.
No. This is Python, not C. You can't increment
Hi.
I've got a question on the differences and how to define static and
class variables. AFAIK, class methods are the ones which receives the
class itself as an argument, while static methods are the one which
runs statically with the defining class.
Hence, my understanding is that static
[EMAIL PROTECTED] wrote:
Hi.
I've got a question on the differences and how to define static and
class variables. AFAIK, class methods are the ones which receives the
class itself as an argument, while static methods are the one which
runs statically with the defining class.
Hence, my
On Tue, 09 Oct 2007 09:16:12 -0700, [EMAIL PROTECTED] wrote:
I've got a question on the differences and how to define static and
class variables.
First you have to define what you mean by static.
AFAIK, class methods are the ones which receives the
class itself as an argument, while static
Your question is variable a
static or class variable? has no real answer. After running the
increment() method on a descendant class, e.g. Child1 will rebind the
name Child1.a, creating a new name in the namespace of the class. So the
variable Foo.a is still there, but you are accessing
On Oct 9, 9:16 am, [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
Hi.
I've got a question on the differences and how to define static and
class variables. AFAIK, class methods are the ones which receives the
class itself as an argument, while static methods are the one which
runs statically with
In point #3, you really bind a name to a value. As you probably know, in
Python, there are names and objects. The initial value of the name 'a'
is 1. It is an immutable object. The += operator usually increments a
value of an object. However, because the 'int' type is immutable, the +=
On Tue, 09 Oct 2007 19:23:37 +0200, Diez B. Roggisch wrote:
Your believes aside, this is simply wrong. The statement
a += x
always leads to a rebinding of a to the result of the operation +.
Not true.
L = []
id(L)
3083496716L
L += [1]
id(L)
3083496716L
It's the same L, not rebound
Steven D'Aprano wrote:
On Tue, 09 Oct 2007 19:23:37 +0200, Diez B. Roggisch wrote:
Your believes aside, this is simply wrong. The statement
a += x
always leads to a rebinding of a to the result of the operation +.
Not true.
Hmm. Or you can write __iadd__ to rebind the name
On Tue, 09 Oct 2007 18:08:34 +, Steven D'Aprano wrote:
L = []
id(L)
3083496716L
L += [1]
id(L)
3083496716L
It's the same L, not rebound at all.
It *is* rebound. To the same object, but it *is* assigned to `L` and not
just mutated in place.
In [107]: class A:
.: a =
Steven D'Aprano schrieb:
On Tue, 09 Oct 2007 19:23:37 +0200, Diez B. Roggisch wrote:
Your believes aside, this is simply wrong. The statement
a += x
always leads to a rebinding of a to the result of the operation +.
Not true.
Yes, it is.
L = []
id(L)
3083496716L
L += [1]
id(L)
On Tue, 09 Oct 2007 19:46:35 +, Marc 'BlackJack' Rintsch wrote:
On Tue, 09 Oct 2007 18:08:34 +, Steven D'Aprano wrote:
L = []
id(L)
3083496716L
L += [1]
id(L)
3083496716L
It's the same L, not rebound at all.
It *is* rebound. To the same object, but it *is* assigned to `L`
On Tue, 09 Oct 2007 22:27:47 +0200, Diez B. Roggisch wrote:
Steven D'Aprano schrieb:
On Tue, 09 Oct 2007 19:23:37 +0200, Diez B. Roggisch wrote:
Your believes aside, this is simply wrong. The statement
a += x
always leads to a rebinding of a to the result of the operation +.
Not true.
On Tue, 09 Oct 2007 21:25:38 +0200, Laszlo Nagy wrote:
a = 1
a+= 1 # The compiler will probably optimize this and the Python bytecode
interpreter will not rebind 'a' here, just increment the integer in
memory.
No. This is Python, not C. You can't increment integers in memory.
Integers are
On Tue, 09 Oct 2007 22:43:16 +, Steven D'Aprano wrote:
On Tue, 09 Oct 2007 19:46:35 +, Marc 'BlackJack' Rintsch wrote:
On Tue, 09 Oct 2007 18:08:34 +, Steven D'Aprano wrote:
L = []
id(L)
3083496716L
L += [1]
id(L)
3083496716L
It's the same L, not rebound at all.
It
[EMAIL PROTECTED] a écrit :
Hi.
I've got a question on the differences and how to define static and
class variables.
What's a static variable ? A variable that doesn't move ?-)
Hence, my understanding is that static variables must be bound to the
class defining the variables
You mean
Marc 'BlackJack' Rintsch a écrit :
On Tue, 09 Oct 2007 18:08:34 +, Steven D'Aprano wrote:
L = []
id(L)
3083496716L
L += [1]
id(L)
3083496716L
It's the same L, not rebound at all.
It *is* rebound. To the same object, but it *is* assigned to `L` and not
just mutated in place.
In
Bruno Desthuilliers a écrit :
(snip)
And it is *not* rebound:
Doh. Stupid me. Of course it is - but to a ref to the same object...
class A:
... l = []
...
class B(A): pass
...
B.__dict__
{'__module__': '__main__', '__doc__': None}
B.l
[]
B.l += [1]
B.__dict__
{'__module__':
40 matches
Mail list logo
