"Antoon Pardon" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On 2006-07-19, Terry Reedy <[EMAIL PROTECTED]> wrote:
>>
>> But I won't. The amount of duplication that can be factored out with
>> augmented assignment depends on the granularity of operations.
>
> I can agree with th
On 2006-07-19, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> "Antoon Pardon" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> So IMV those preparation before the attachment, belong to
>> whatever the interpreter does before it actually attaches
>> an object to a name/slot.
>>
>> So t
"Antoon Pardon" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>> Try some personal introspection. When you act as a Python interpreter,
>> what do you do?
>
> I do the evaluation of the target in the __setitem__ method
> (or the STORE_SUBSCR opcode).
I meant mentally, in your mind
Antoon Pardon wrote:
> The language reference doesn't talk about objects. And IMO you
> should be carefull if you want to use the word "object" here.
> In the line: "foo += 1", you can't talk about the object foo,
> since foo will
possibly
> be bound to a different object after the assignment
>
On 2006-07-18, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> "Antoon Pardon" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> On 2006-07-17, Terry Reedy <[EMAIL PROTECTED]> wrote:
>>> Or, whether docs (and reasonable interpretation thereof) and
>>> implementation match, which I claim
> Antoon Pardon <[EMAIL PROTECTED]> (AP) wrote:
>AP> On 2006-07-17, Piet van Oostrum <[EMAIL PROTECTED]> wrote:
Antoon Pardon <[EMAIL PROTECTED]> (AP) wrote:
>>>
>AP> On 2006-07-14, Piet van Oostrum <[EMAIL PROTECTED]> wrote:
>>>
>> Just read what it says. `It is only evaluated
"Antoon Pardon" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On 2006-07-17, Terry Reedy <[EMAIL PROTECTED]> wrote:
>> Or, whether docs (and reasonable interpretation thereof) and
>> implementation match, which I claim they do it this case.
The claim, in reference to the CPython
Antoon Pardon wrote:
>
> Now maybe I'm just not bright enough, so maybe you can explain what
> something like col['t'] is evaluated to in a statement like:
>
> col['t'] = exp
In the notation given earlier, let us say that it would be this:
namespace = col
setitem(namespace, "t", exp)
Note that
On 2006-07-17, Terry Reedy <[EMAIL PROTECTED]> wrote:
> "Antoon Pardon" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> On 2006-07-15, Terry Reedy <[EMAIL PROTECTED]> wrote:
>>> The problem with understanding augmented assignment is that it directs
>>> the
>>> compiler and inte
On 2006-07-17, Paul Boddie <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>>
>> What the language reference should have said IMO is that in case x
>> is an attribute reference, index or slicing, the primary expression
>> will be evaluated only once, as will be the index or slice in the
>> two la
On 2006-07-17, Piet van Oostrum <[EMAIL PROTECTED]> wrote:
>> Antoon Pardon <[EMAIL PROTECTED]> (AP) wrote:
>
>>AP> On 2006-07-14, Piet van Oostrum <[EMAIL PROTECTED]> wrote:
>
Just read what it says. `It is only evaluated once' is quite clear I would
say.
>
>>AP> If it is so clear, w
"Antoon Pardon" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On 2006-07-15, Terry Reedy <[EMAIL PROTECTED]> wrote:
>> The problem with understanding augmented assignment is that it directs
>> the
>> compiler and interpreter to do one or maybe two mostly invisible
>> optimizatio
"Antoon Pardon" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On 2006-07-15, Terry Reedy <[EMAIL PROTECTED]> wrote:
>> The problem with understanding augmented assignment is that it directs
>> the
>> compiler and interpreter to do one or maybe two mostly invisible
>> optimizatio
> Antoon Pardon <[EMAIL PROTECTED]> (AP) wrote:
>AP> On 2006-07-14, Piet van Oostrum <[EMAIL PROTECTED]> wrote:
>>> Just read what it says. `It is only evaluated once' is quite clear I would
>>> say.
>AP> If it is so clear, why don't you explain it?
I have done that in another thread.
>>>
Antoon Pardon wrote:
>
> What the language reference should have said IMO is that in case x
> is an attribute reference, index or slicing, the primary expression
> will be evaluated only once, as will be the index or slice in the
> two latter cases.
I think the difficulty here for the author of th
On 2006-07-15, Terry Reedy <[EMAIL PROTECTED]> wrote:
> The problem with understanding augmented assignment is that it directs the
> compiler and interpreter to do one or maybe two mostly invisible
> optimizations. To me, the effective meaning of 'evalutating once versus
> twice' is most easil
On 2006-07-14, Piet van Oostrum <[EMAIL PROTECTED]> wrote:
>> Antoon Pardon <[EMAIL PROTECTED]> (AP) wrote:
>
>>AP> Well I'll start on an possitive note and accept this. Now I'd like you
>>AP> to answer some questions.
>
>>AP> 1) Do you think the langauge reference makes it clear that this is h
> Gerhard Fiedler <[EMAIL PROTECTED]> (GF) wrote:
>GF> On 2006-07-14 16:07:28, Piet van Oostrum wrote:
>AP> 2a) In case you answer yes to question (1). Can you explain me how
>AP> I have to read the language reference in order to deduce this
>AP> is indeed the way things should be understood.
The problem with understanding augmented assignment is that it directs the
compiler and interpreter to do one or maybe two mostly invisible
optimizations. To me, the effective meaning of 'evalutating once versus
twice' is most easily seen in the byte code generated by what is, remember,
the r
On 2006-07-14 16:07:28, Piet van Oostrum wrote:
>>AP> 2a) In case you answer yes to question (1). Can you explain me how
>>AP> I have to read the language reference in order to deduce this
>>AP> is indeed the way things should be understood.
>
> Just read what it says. `It is only evaluat
> Antoon Pardon <[EMAIL PROTECTED]> (AP) wrote:
>AP> Well I'll start on an possitive note and accept this. Now I'd like you
>AP> to answer some questions.
>AP> 1) Do you think the langauge reference makes it clear that this is how
>AP>the reader has to understand things.
Yes.
>AP> 2a) I
On 2006-07-11, Piet van Oostrum <[EMAIL PROTECTED]> wrote:
>> Antoon Pardon <[EMAIL PROTECTED]> (AP) wrote:
>
>>AP> As I read the language reference the x stands for a target expression.
>>AP> Now what does it mean to evaluate a target expression like col[key].
>>AP> IMO it means finding the lo
> Antoon Pardon <[EMAIL PROTECTED]> (AP) wrote:
>AP> As I read the language reference the x stands for a target expression.
>AP> Now what does it mean to evaluate a target expression like col[key].
>AP> IMO it means finding the location of the item in the collection: the
>AP> bucket in the dir
On 2006-07-10, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> "Antoon Pardon" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> I disagree. The += version only evaluates the index once, but still has
>> to find the object twice.
>
> No it does not *have* to find the object twice and no
"Antoon Pardon" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I disagree. The += version only evaluates the index once, but still has
> to find the object twice.
No it does not *have* to find the object twice and no it does *not* find
the object twice. From the viewpoint of the
On 2006-07-10, Jim Segrave <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> Antoon Pardon <[EMAIL PROTECTED]> wrote:
>>On 2006-07-09, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>>> Frank Millman wrote:
>>>
So it looks as if x += [] modifies the list in place, while x = x + []
>>>
In article <[EMAIL PROTECTED]>,
Antoon Pardon <[EMAIL PROTECTED]> wrote:
>On 2006-07-09, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>> Frank Millman wrote:
>>
>>> So it looks as if x += [] modifies the list in place, while x = x + []
>>> creates a new list.
>>
>> objects can override the += operato
On 2006-07-09, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Frank Millman wrote:
>
>> So it looks as if x += [] modifies the list in place, while x = x + []
>> creates a new list.
>
> objects can override the += operator (by defining the __iadd__ method),
> and the list type maps __iadd__ to extend
Frank Millman wrote:
> So it looks as if x += [] modifies the list in place, while x = x + []
> creates a new list.
objects can override the += operator (by defining the __iadd__ method),
and the list type maps __iadd__ to extend. other containers may treat
+= differently, but in-place behavi
Frank Millman wrote:
> nagy wrote:
>
>>Thanks, Kirk.
>>I considered the += as only a shorthand notation for the assignment
>>operator.
>>Since for lists + is simply a concatetation, I am not sure it x=x+[2]
>>is creating a brand
>>new list. Could you refer me to any documentation on this?
>>Thanks
nagy wrote:
> Thanks, Kirk.
> I considered the += as only a shorthand notation for the assignment
> operator.
> Since for lists + is simply a concatetation, I am not sure it x=x+[2]
> is creating a brand
> new list. Could you refer me to any documentation on this?
> Thanks,
> Nagy
My habit is to
nagy wrote:
> Thanks, Kirk.
> I considered the += as only a shorthand notation for the assignment
> operator.
> Since for lists + is simply a concatetation, I am not sure it x=x+[2]
> is creating a brand
> new list. Could you refer me to any documentation on this?
Yes:
http://docs.python.org/ref/
Looks like x=x+[2] creats a new list to me:
>>> b = [8,5,6]
>>> x = b
>>> x = x + [2]
>>> print b,x
[8, 5, 6] [8, 5, 6, 2]
-Chris
On Sat, Jul 08, 2006 at 11:56:11AM -0700, nagy wrote:
> Thanks, Kirk.
> I considered the += as only a shorthand notation for the assignment
> operator.
> Since for list
Thanks, Kirk.
I considered the += as only a shorthand notation for the assignment
operator.
Since for lists + is simply a concatetation, I am not sure it x=x+[2]
is creating a brand
new list. Could you refer me to any documentation on this?
Thanks,
Nagy
Kirk McDonald wrote:
> nagy wrote:
> > I do t
nagy wrote:
> I do the following. First create lists x,y,z. Then add an element to x
> using the augumented assignment operator. This causes all the other
> lists to be changed also.
> But if I use the assignment x=x+[4] instead of using the augumented
> assignment, the y and z lists do not change.
I do the following. First create lists x,y,z. Then add an element to x
using the augumented assignment operator. This causes all the other
lists to be changed also.
But if I use the assignment x=x+[4] instead of using the augumented
assignment, the y and z lists do not change.
Why is that?
This doe
36 matches
Mail list logo
