In article <owen-1704951230220001@rowen.astro.washington.edu> owen@astro.washington.edu (Russell E. Owen) writes:
>I've just started learning Python, and had some questions about possible
>design issues -- whether or not they are flaws, and if flaws, how serious:
>
>jredford@lehman.com wrote (in the ongoing language comparison):
>> ...Python's practice of throwing around
>> namespaces in the interpreted langauge makes it _inheriently_
>> untrustworthy. ...
This is false, again.
>This was bothering me, too, as I worked through the excellent tutorial. It
>looks like a potentially nasty source of errors. What do Python mavens
>think? Is it a problem?
I don't think so. To make it a problem you have to make it a problem,
and then it's your problem, not Python's.
Late bindings and such can be useful however. Consider:
def slowfunction(...):
# slow code that will work in any environment
def fastfunction(...):
# faster version that requires os specific features
if os_is_good:
neat_function = fastfunction
else:
neat_function = slowfunction
...
neat_function(...)
Here the module can be imported even if the stuff needed
for fastfunction doesn't exist on your platform. This won't
be a problem, because it won't be used. You could even write
if os_is_good:
import fastmodule
neatmodule = fastmodule
else:
import slowmodule
neatmodule = slowmodule
...
neatmodule.neatfunction(...)
and save the interpreter some work. -a.
====
The administration wants me to spend a lot of money on hardware in the
next couple months. This is a problem because everything I want to
buy has gotten so cheap. Just dealing with all that crud is more work
than I want! This is one of the hazards of working in the computer
industry.