Is an interactive command a block?

Alf P. Steinbach alfps at start.no
Thu Nov 19 16:42:31 EST 2009


* Steven D'Aprano:
> On Thu, 19 Nov 2009 21:37:17 +0100, Alf P. Steinbach wrote:
> 
>> The CPython 3.1.1 language reference §4.1 says
>>
>>    "Each command typed interactively is a block."
>>
>> It also says
>>
>>    "If a name is bound in a block, it is a local variable of that block,
>>    unless
>>     declared as nonlocal"
>>
>> Even with a non-literal try-for-best-meaning reading I can't get this to
>> mesh with the actual behavior of the interpreter, e.g.
>>
>>    >>> for x in "poi":
>>    ...    fandango = 666
>>    ...
>>    >>> fandango
>>    666
>>    >>> _
>>
>> My current understanding is (A) that the interpreter is correct in this
>> respect (for one would harldly want the effects of statements to be
>> fundamentally different in interpreted mode, except the presentation of
>> expression results), and (B), but here I'm less sure, that the
>> documentation is incorrect.
> 
> 
> Why do you say that? I don't see what it is in the command you typed that 
> leads you to think the documentation is incorrect.
> 
> The first command you type is:
> 
> for x in "poi":
>     fandango = 666
> 
> 
> which binds two names, x and fandango. Since you are not typing them in a 
> function or class definition, locals() is globals() and the two local 
> names you create happen to also be globals.

Thanks, that may be it.

In most other languages I'm familiar with, if a name is local then it isn't 
global (and vice versa), and I had that as an underlying assumption since it 
doesn't appear to be mentioned in the documentation.

However, I find a language reference statement that alludes to this: "(The 
variables of the module code block are local and global.)"

Hm...


> The next two commands you type:
> 
> fandango
> _
> 
> don't bind anything, so aren't relevant.

Well it showed that 'fandango' had been defined as a global. :-)


> If it helps:
> 
> 
>>>> for x in "poi":
> ...     fandango = 666
> ...
>>>> locals() is globals()
> True
>>>> fandango
> 666
>>>> locals()['fandango']
> 666
>>>> import __main__
>>>> __main__.fandango
> 666

Yeah, helps.

I feel that there's still something lacking in my understanding though, like 
how/where the "really actually just pure local not also global" is defined for 
function definition, but it's now just a vague feeling of something missing, not 
a feeling of direct contradiction as I had when I believed local != global.


Cheers, & thanks,

- Alf



More information about the Python-list mailing list