Aahz wrote:
> In article ,
> Steve Holden wrote:
>> I understand what you are saying, but if the id() associated with a name
>> doesn't change after augmented assignment it seems a little wrong-headed
>> to argue that "the augmented assignment always binds a new value to the
>> name".
>>
>> What
In article ,
Steve Holden wrote:
>
>I understand what you are saying, but if the id() associated with a name
>doesn't change after augmented assignment it seems a little wrong-headed
>to argue that "the augmented assignment always binds a new value to the
>name".
>
>What you are actually saying i
Aahz wrote:
> In article <87hc3un1vn.fsf@metalzone.distorted.org.uk>,
> Mark Wooding wrote:
>> * Python augmented-assignment (`+=', for example) is inconsistent.
>>Depending on what type of object the left-hand side evaluates to, it
>>may /either/ mutate that object, /or/ assign a ne
a...@pythoncraft.com (Aahz) writes:
> Actually, that is not correct.
You're right, evidently.
[snip]
a
> (1, ['foo', 'bar'], 'xyzzy')
a[1] += ['spam']
> Traceback (most recent call last):
> File "", line 1, in ?
> TypeError: object doesn't support item assignment
a
> (1, ['foo
In article <87hc3un1vn.fsf@metalzone.distorted.org.uk>,
Mark Wooding wrote:
>
> * Python augmented-assignment (`+=', for example) is inconsistent.
>Depending on what type of object the left-hand side evaluates to, it
>may /either/ mutate that object, /or/ assign a new value to the
>
Steven D'Aprano writes:
> There's a practical reason too. You create a new Foo instance, mutate
> it with the augmented assignment operator, and then a tenth of a
> millisecond later the garbage collector throws it away because it has
> a reference count of zero.
Only in this specific example.
On Sun, 18 Jan 2009 15:11:46 -0500, Terry Reedy wrote:
> andrew cooke wrote:
>> Context -
>> http://docs.python.org/3.0/reference/datamodel.html?highlight=data
>> model#object.__iadd__
>>
>> Just a suggestion I thought I'd throw out... There's a restriction in
>> the language implementation on e
andrew cooke wrote:
Context - http://docs.python.org/3.0/reference/datamodel.html?highlight=data
model#object.__iadd__
Just a suggestion I thought I'd throw out... There's a restriction in
the language implementation on exactly what can go the left of an
augmented arithmetic expression.
For ex
Improved link -
http://docs.python.org/3.0/reference/datamodel.html#object.__iadd__
--
http://mail.python.org/mailman/listinfo/python-list
On Jan 18, 6:56 am, andrew cooke wrote:
> On Jan 18, 9:40 am, Marc 'BlackJack' Rintsch wrote:
>
> > On Sun, 18 Jan 2009 04:24:04 -0800, andrew cooke wrote:
> > > my argument was that *= is not treated as = and *, but as a completely
> > > new operator (the docs even say that the implementation ne
http://bugs.python.org/issue4986
Sorry for the noise,
Andrew
--
http://mail.python.org/mailman/listinfo/python-list
On Jan 18, 9:56 am, andrew cooke wrote:
> either i have misundertstood you
ah, i see your point. sorry, andrew
--
http://mail.python.org/mailman/listinfo/python-list
On Jan 18, 9:40 am, Marc 'BlackJack' Rintsch wrote:
> On Sun, 18 Jan 2009 04:24:04 -0800, andrew cooke wrote:
> > my argument was that *= is not treated as = and *, but as a completely
> > new operator (the docs even say that the implementation need not return
> > self which suggests some pretty e
On Sun, 18 Jan 2009 04:24:04 -0800, andrew cooke wrote:
> my argument was that *= is not treated as = and *, but as a completely
> new operator (the docs even say that the implementation need not return
> self which suggests some pretty extreme semantics were envisaged).
What do you mean by "sugg
On Jan 18, 9:01 am, Chris Rebert wrote:
> Indeed. Python happens to in this case draw the line at using the
> augmented assignment operators for non-assignment. I personally see
> this as reasonable because the = symbol has a consistent meaning in
> Python (assignment) whereas the other plain oper
Not sure if you were saying this, but the underlying technical reason
for this issue is that they are treated as assignment rather than
operators in the language spec -
http://docs.python.org/3.0/reference/simple_stmts.html#augmented-assignment-statements
I think this explains why they are not li
On Sun, Jan 18, 2009 at 3:42 AM, andrew cooke wrote:
>> Therefore, Python requires you to rewrite the code in some other way
>> that makes your intentions more clear. For instance, why not use the
>> << operator instead?
>
> Right, but you're guessing what the context is. Within a DSL it often
>
> Therefore, Python requires you to rewrite the code in some other way
> that makes your intentions more clear. For instance, why not use the
> << operator instead?
Right, but you're guessing what the context is. Within a DSL it often
makes a lot of sense to use operators for reasons that weren't
On Sun, Jan 18, 2009 at 2:56 AM, andrew cooke wrote:
> Context - http://docs.python.org/3.0/reference/datamodel.html?highlight=data
> model#object.__iadd__
>
> Just a suggestion I thought I'd throw out... There's a restriction in
> the language implementation on exactly what can go the left of an
Context - http://docs.python.org/3.0/reference/datamodel.html?highlight=data
model#object.__iadd__
Just a suggestion I thought I'd throw out... There's a restriction in
the language implementation on exactly what can go the left of an
augmented arithmetic expression.
For example:
>>> a = 3
>>> a
20 matches
Mail list logo
