Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #73868 > unrolled thread

TypeError expected in an augmented assignment

Back to article view | Back to comp.lang.python

Contents

  TypeError expected in an augmented assignment candide <c.candide@laposte.net> - 2014-07-02 19:39 -0700
    Re: TypeError expected in an augmented assignment Terry Reedy <tjreedy@udel.edu> - 2014-07-02 22:57 -0400
      Re: TypeError expected in an augmented assignment candide <c.candide@laposte.net> - 2014-07-03 00:51 -0700
        Re: TypeError expected in an augmented assignment Chris Angelico <rosuav@gmail.com> - 2014-07-03 18:36 +1000
          Re: TypeError expected in an augmented assignment candide <c.candide@laposte.net> - 2014-07-03 02:35 -0700
            Re: TypeError expected in an augmented assignment Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-07-03 13:43 +0100

#73868 — TypeError expected in an augmented assignment

An hybrid list-tuple concatenation is not allowed

>>> []+(1, 2)
Traceback (most recent call last):                                                                        
  File "<stdin>", line 1, in <module>                                                                     
TypeError: can only concatenate list (not "tuple") to list                                                
>>>  



hence I was expecting (*) that the following code raises a TypeError :

>>> x = []                                                                                                
>>> x += (1, 2)                                                                                           
>>> x                                                                                                     
[1, 2]                                                                                                    
>>>


Any explanation ?


(*) as the docs states, the augmented assignment is supposed to perform the concatenation : 
An augmented assignment (...) performs the binary operation specific to the type of assignment on the two operands (...)

[toc] | [next] | [standalone]

#73870

On 7/2/2014 10:39 PM, candide wrote:
> An hybrid list-tuple concatenation is not allowed
>
>>>> []+(1, 2)
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
> TypeError: can only concatenate list (not "tuple") to list
>>>>
>
>
>
> hence I was expecting (*) that the following code raises a TypeError :
>
>>>> x = []
>>>> x += (1, 2)
>>>> x
> [1, 2]
>>>>
>
>
> Any explanation ?
 >>> seq = [1,2]
 >>> seq.extend((3,4))
 >>> seq+= {5, 6}  # the order of extending is not determined
 >>> seq
[1, 2, 3, 4, 5, 6]
 >>>

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#73885

>  >>> seq = [1,2]
> 
>  >>> seq.extend((3,4))


OK, this feature is referenced in the Python Library reference here : 

https://docs.python.org/3.2/library/stdtypes.html#typesseq-mutable

not thoroughly referenced but, anyway, referenced.





> 
>  >>> seq+= {5, 6}  # the order of extending is not determined
> 
>  >>> seq
> 
> [1, 2, 3, 4, 5, 6]
> 
>  >>>

Good and interesting observation. But I can't find out where this feature is referenced in the Language/Library Reference. Because, as my first post explains, augmented assignment performs the binary operation associated to the augmented assignment, cf. 

https://docs.python.org/3.2/reference/simple_stmts.html#augmented-assignment-statements

so seq+= {5, 6} performs seq + {5, 6}, the later raising a TypeError.

[toc] | [prev] | [next] | [standalone]

#73887

On Thu, Jul 3, 2014 at 5:51 PM, candide <c.candide@laposte.net> wrote:
> Good and interesting observation. But I can't find out where this feature is referenced in the Language/Library Reference. Because, as my first post explains, augmented assignment performs the binary operation associated to the augmented assignment, cf.
>
> https://docs.python.org/3.2/reference/simple_stmts.html#augmented-assignment-statements
>
> so seq+= {5, 6} performs seq + {5, 6}, the later raising a TypeError.

>From that link:

"""
An augmented assignment expression like x += 1 can be rewritten as x =
x + 1 to achieve a similar, but not exactly equal effect. In the
augmented version, x is only evaluated once. Also, when possible, the
actual operation is performed in-place, meaning that rather than
creating a new object and assigning that to the target, the old object
is modified instead.
"""

The significance here is that the augmented assignment may not
necessarily be at all comparable to the non-augmented version, but
ought to have *approximately* the same *intention*. There are plenty
of situations where the two will differ, eg when there are multiple
references to the same object:

>>> a = b = [1,2]
>>> a += [3]
>>> a,b
([1, 2, 3], [1, 2, 3])
>>> a = a + [4]
>>> a,b
([1, 2, 3, 4], [1, 2, 3])

In its simplest form, x += 1 <-> x = x + 1, but there are plenty of
ways to distinguish them.

ChrisA

[toc] | [prev] | [next] | [standalone]

#73891

> >From that link:
> 
> 
> 
> """
> 
> An augmented assignment expression like x += 1 can be rewritten as x =
> 
> x + 1 to achieve a similar, but not exactly equal effect. In the
> 
> augmented version, x is only evaluated once. Also, when possible, the
> 
> actual operation is performed in-place, meaning that rather than
> 
> creating a new object and assigning that to the target, the old object
> 
> is modified instead.
> 
> """
> 
> 
> 
> The significance here is that the augmented assignment may not
> 
> necessarily be at all comparable to the non-augmented version, but
> 
> ought to have *approximately* the same *intention*. 


This is not my reading. 




> 
> of situations where the two will differ, eg when there are multiple
> 
> references to the same object:
> 
> 
> 
> >>> a = b = [1,2]
> 
> >>> a += [3]
> 
> >>> a,b
> 
> ([1, 2, 3], [1, 2, 3])
> 
> >>> a = a + [4]
> 
> >>> a,b
> 
> ([1, 2, 3, 4], [1, 2, 3])
> 
> 

OK but this behavior is in conformance with the Reference Manual (cf. your quote above : "when possible, the actual operation is performed in-place"). This is not my point because the doc explictly claims that "an augmented assignment [...] performs the binary operation specific to the type of assignment on the two operands".

[toc] | [prev] | [next] | [standalone]

#73899

On 03/07/2014 10:35, candide wrote:
>
>
>> >From that link:
>>
>>
>>
>> """
>>
>> An augmented assignment expression like x += 1 can be rewritten as x =
>>
>> x + 1 to achieve a similar, but not exactly equal effect. In the
>>
>> augmented version, x is only evaluated once. Also, when possible, the
>>
>> actual operation is performed in-place, meaning that rather than
>>
>> creating a new object and assigning that to the target, the old object
>>
>> is modified instead.
>>
>> """
>>
>>
>>
>> The significance here is that the augmented assignment may not
>>
>> necessarily be at all comparable to the non-augmented version, but
>>
>> ought to have *approximately* the same *intention*.
>
>
> This is not my reading.
>
>
>
>
>>
>> of situations where the two will differ, eg when there are multiple
>>
>> references to the same object:
>>
>>
>>
>>>>> a = b = [1,2]
>>
>>>>> a += [3]
>>
>>>>> a,b
>>
>> ([1, 2, 3], [1, 2, 3])
>>
>>>>> a = a + [4]
>>
>>>>> a,b
>>
>> ([1, 2, 3, 4], [1, 2, 3])
>>
>>
>
> OK but this behavior is in conformance with the Reference Manual (cf. your quote above : "when possible, the actual operation is performed in-place"). This is not my point because the doc explictly claims that "an augmented assignment [...] performs the binary operation specific to the type of assignment on the two operands".
>

To get the wording changed to satisfy yourself, either raise an issue on 
the bug tracker at bugs.python.org and attach a patch file, or send an 
email with suggested wording to docs@python.org.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web