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 the evaluation of
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 that. But until
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 they do it this
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
than it
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 ;-)
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, why don't you explain it?
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 latter cases.
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 interpreter to do one or
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 in my
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 [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 once' is quite clear I
would
say.
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 how
APthe reader
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 easily
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 this
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.
Your problem is that
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
optimizations. To me,
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
optimizations. To me,
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.
Just read
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
APthe reader has to understand things.
Yes.
AP 2a) In case you
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 evaluated once'
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
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 location of the item
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 it does *not*
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 directory, the
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. other
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 += operator (by defining 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 + []
creates a new list.
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
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 check
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
My
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
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 the
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 lists + is simply a
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:
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
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.
36 matches
Mail list logo
