Yield after the return in Python function.

Terry Reedy tjreedy at udel.edu
Mon Apr 5 21:42:34 EDT 2021


On 4/5/2021 3:32 PM, Chris Angelico wrote:

> On Tue, Apr 6, 2021 at 5:14 AM Terry Reedy <tjreedy at udel.edu> wrote:
>> Python *could* do the same for expresssions: load 'a' (in this case)
>> once into a register or stack slot and use that value consistently
>> throughout the expression.  Replacing the eval with the following exec
>> has the same effect.
> 
> True, but I think that this would be enough of a semantic change that
> Python should be very VERY careful about doing it.

I consider it beyond a possibility.

> A *programmer* can
> choose to do this (and we see it sometimes as an optimization, since
> global lookups can be a lot more costly), but the interpreter
> shouldn't.

Agreed.  My interest is in elucidating the different between math and 
computing.  The reason some prohibit rebinding bound names within a 
local context is to make code more like math.  But this example should 
that Python code can effectively rebind names 'invisibly'.

Side note: Since a loop is equivalent to a recursive tail call, I think 
rebinding once per loop should be considered to be consistent with 
no-rebinding.  When an compiler or interpreter re-writes tail recursion 
as while looping, the result is the same.  I don't believe in forcing 
people to take the detour of using recursion syntax, which for many is 
harder to write and understand.


>> exec("tem=a; print(tem and not tem)", Wat(print=print))
>> # print False
>>
>> In this example, one could disable the binding with __setitem__
>> (resulting in printing 0), but python code cannot disable internal
>> register or stack assignments.

> Indeed. That said, though, I think that any namespace in which
> referencing the same simple name more than once produces this sort of
> bizarre behaviour should be considered, well, unusual. NORMAL code
> won't have to concern itself with this. But the language spec doesn't
> require us to write normal code......

I believe in the freedom to write 'strange code'.  But my other interest 
is how to talk about Python and 'normal' code.

-- 
Terry Jan Reedy



More information about the Python-list mailing list