Easy questions from a python beginner

[Alf P. Steinbach /Usenet]

* MRAB, on 12.07.2010 04:09:
> Alf P. Steinbach /Usenet wrote:
>> * MRAB, on 12.07.2010 00:37:
>>> Alf P. Steinbach /Usenet wrote:
>>>> * Stephen Hansen, on 11.07.2010 21:00:
>>>>> On 7/11/10 11:45 AM, wheres pythonmonks wrote:
>>>>>> Follow-up:
>>>>>> Is there a way to define compile-time constants in python and have
>>>>>> the
>>>>>> bytecode compiler optimize away expressions like:
>>>>>>
>>>>>> if is_my_extra_debugging_on: print ...
>>>>>>
>>>>>> when "is_my_extra_debugging" is set to false? I'd like to pay no
>>>>>> run-time penalty for such code when extra_debugging is disabled.
>>>>>
>>>>> Any code wrapped in a __debug__ guard is utterly ommitted if you run
>>>>> Python with the -O option. That, and asserts go away.
>>>>>
>>>>>> On #2: My point regarding the impossibility of writing the swap
>>>>>> function for ints is to explicitly understand that this isn't
>>>>>> possible, so as not to look for solutions along those lines when
>>>>>> trying to write python code.
>>>>>
>>>>> Its impossible because Python's calling and namespace semantics simply
>>>>> don't work like that. There's no references in the traditional sense,
>>>>> because there's no variables-- boxes that you put values in. There's
>>>>> just concrete objects. Objects are passed into the function and given
>>>>> new names; that those objects have names in the enclosing scope is
>>>>> something you don't know, can't access, and can't manipulate.. even
>>>>> the
>>>>> objects don't know what names they happen to be called.
>>>>>
>>>>> Check out http://effbot.org/zone/call-by-object.htm
>>>>
>>>> Oh, I wouldn't give that advice. It's meaningless mumbo-jumbo. Python
>>>> works like Java in this respect, that's all; neither Java nor Python
>>>> support 'swap'.
>>>>
>>>> Of course there are variables, that's why the docs call them variables.
>>>>
>>> In Java a variable is declared and exists even before the first
>>> assignment to it. In Python a 'variable' isn't declared and won't exist
>>> until the first 'assignment' to it.
>>
>> That is a misconception.
>>
>> In Python a variable is declared by having an assignment to it, which
>> for a local variable may be anywhere within a routine.
>>
>> If such a variable is used before it's been assigned to, then you get
>> an uninitialized variable exception. Clearly the variable must exist
>> in order for the exception to refer to it (not to mention the
>> exception occurring at all).
>>
>> def foo():
>> print( blah )
>> blah = "this is both an assignment and a declaration causing it to exist"
>>
>> foo()
>>
>> Clearly when the exception is raised, referring to the variable, the
>> variable exists.
>>
>> Contrary to your statement that is before the assignment.
>>
>> However, as stated up-thread, I do not expect facts, logic or general
>> reasoning to have any effect whatsoever on such hard-core religious
>> beliefs. And I do not care whether I convince you or not. But I *do
>> not* want the religious subset of the community to succeed too much in
>> propagating nonsense idiot beliefs to newbies -- hence the concrete
>> example that any newbie can try.
>>
> How about this:
>
>  >>> def foo():
> print("Before:", locals())
> x = 0
> print("After:", locals())
>
>
>  >>> foo()
> Before: {}
> After: {'x': 0}

How about it?

Note that you get the same result if you do

     x = "blah"
     def foo():
         # print( x )  # Causes uninitialized variable exception here
         print( "Before:", locals() )
         x = 0
         print( "After:", locals() )

However, if you remove the local assignment to x, then the out-commented print 
statement will no longer cause an exception, it will then refer to the global.

The reason that it does throw an exception when you do have the local 
assignment, is that the local x exists at that point. If it didn't exist it 
could not have any effect. Things that don't exist generally have no effect, 
except in the minds of the religious, like angels and so on.

On the basis of what locals() reports it should be OK to refer to the global x 
as above. Judging by locals(), there's no local x that could get in the way. But 
since it is not OK to refer to the global x, the result of locals() has nothing 
to do with that: it doesn't tell you about the local x  --  and no, the Python 
interpreter does not look forward in time to see that it will appear.

In passing, I should perhaps have told you up front, your argument has nothing 
substantial to do with the article you originally responded to, about the 
semantics of variables. Your argument is the assertion that different languages 
can't have similar or identical semantics for some feature. That's nonsense in 
itself, plus, as you've seen, the difference that you focused on is not there, 
and, third, what you do maintain is not there, doesn't exist, has a real effect.


Cheers & hth.,

- Alf

-- 
blog at <url: http://alfps.wordpress.com>