"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,
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 variabl
40 matches
Mail list logo
