* 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>
--
http://mail.python.org/mailman/listinfo/python-list
