"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
>> rational
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
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`
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):
>
> > >>
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 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
>>
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 inter
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
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 t
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:
http://www.python.org/dev/peps/
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
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
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,
[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,
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:
>
>
[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, 10:00 am, Duncan Booth <[EMAIL PROTECTED]>
wrote:
> [EMAIL PROTECTED] wrote:
> > On Oct 10, 8:23 am, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
>
> >> rebinds a. Period. Which is the _essential_ thing in my post, because
> >> this rebinding semantics are what confused the OP.
>
> > D
[EMAIL PROTECTED] wrote:
> On Oct 10, 8:23 am, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
>> 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.
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 do
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 +=
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
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
>> 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 + opera
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__
{'__m
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`
[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
Yo
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'
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 ar
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 operat
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 objec
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)
> 30834967
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:
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
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
> 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 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 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 acce
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 st
[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,
39 matches
Mail list logo
