[Python-Dev] [PEP] += on return of function call result

[Luke Kenneth Casson Leighton]

jeff,

beat bolli's code example:

	count[word] = count.get(word, 0) + 1

i think best illustrates what issue you are trying to raise.

okay, we know there are two issues so let's give an example
that removes one of those issues:

	count = {}

	count[word] = count.get(word, []) + ['hello']

the issue is that the difference between the above 'hello'
example and this:

	count.get(word, []) += ['hello']

is that you don't know what STORE to use after the use of get()
in the second example, but you do in the first example because
it's explicity set out.

so, does this help illustrate what might be done?

if it's possible to return a result and know what should be done
with it, then surely it should be possible to return a result from
a += "function" and know what should be done with it?

l.



On Sat, May 17, 2003 at 10:21:39AM -0500, Jeff Epler wrote:
> I think that looking at the generated bytecode is useful.
> 
> # Running with 'python -O'
> >>> def f(x): x += 1
> >>> dis.dis(f)
>           0 LOAD_FAST                0 (x)
>           3 LOAD_CONST               1 (1)
>           6 INPLACE_ADD         
>           7 STORE_FAST               0 (x)    ***
>          10 LOAD_CONST               0 (None)
>          13 RETURN_VALUE        
> >>> def g(x): x[0] += 1
> >>> dis.dis(g)
>           0 LOAD_GLOBAL              0 (x)
>           3 LOAD_CONST               1 (0)
>           6 DUP_TOPX                 2
>           9 BINARY_SUBSCR       
>          10 LOAD_CONST               2 (1)
>          13 INPLACE_ADD         
>          14 ROT_THREE           
>          15 STORE_SUBSCR                      ***
>          16 LOAD_CONST               0 (None)
>          19 RETURN_VALUE        
> >>> def h(x): x.a += 1
> >>> dis.dis(h)
>           0 LOAD_GLOBAL              0 (x)
>           3 DUP_TOP             
>           4 LOAD_ATTR                1 (a)
>           7 LOAD_CONST               1 (1)
>          10 INPLACE_ADD         
>          11 ROT_TWO             
>          12 STORE_ATTR               1 (a)    ***
>          15 LOAD_CONST               0 (None)
>          18 RETURN_VALUE        
> 
> In each case, there's a STORE step to the inplace statement.  In the case of the proposed
> 	def j(x): x() += 1
> what STORE instruction would you use?
> 
> >>> [opname for opname in dis.opname if opname.startswith("STORE")]
> ['STORE_SLICE+0', 'STORE_SLICE+1', 'STORE_SLICE+2', 'STORE_SLICE+3',
>  'STORE_SUBSCR', 'STORE_NAME', 'STORE_ATTR', 'STORE_GLOBAL', 'STORE_FAST',
>  'STORE_DEREF']
> 
> If you don't want one from the list, then you're looking at substantial
> changes to Python.. (and STORE_DEREF probably doesn't do anything that's
> relevant to this situation, though the name sure sounds promising,
> doesn't it)
> 
> Jeff

-- 
-- 
expecting email to be received and understood is a bit like
picking up the telephone and immediately dialing without
checking for a dial-tone; speaking immediately without listening
for either an answer or ring-tone; hanging up immediately and
then expecting someone to call you (and to be able to call you).
--
every day, people send out email expecting it to be received
without being tampered with, read by other people, delayed or
simply - without prejudice but lots of incompetence - destroyed.
--
please therefore treat email more like you would a CB radio
to communicate across the world (via relaying stations):
ask and expect people to confirm receipt; send nothing that
you don't mind everyone in the world knowing about...