"no variable or argument declarations are necessary."

[bruno modulix]

James A. Donald wrote:
> I am contemplating getting into Python, which is used by engineers I
> admire - google and Bram Cohen, but was horrified 

"horrified" ???

Ok, so I'll give you more reasons to be 'horrified':
- no private/protected/public access restriction - it's just a matter of
conventions ('_myvar' -> protected, '__myvar' -> private)
- no constants (here again just a convention : a name in all uppercase
is considered a constant - but nothing will prevent anyone to modify it)
- possibility to add/delete attributes to an object at runtime
- possibility to modify a class at runtime
- possibility to change the class of an object at runtime
- possibility to rebind a function name at runtime
....

If you find all this horrifying too, then hi-level dynamic languages are
not for you !-)

> to read
> 
> "no variable or argument declarations are necessary."

No declarative static typing is necessary - which not the same thing. In
Python, type informations belong to the object, not to names that are
bound to the object.

Of course you cannot use a variable that is not defined ('defining' a
variable in Python being just a matter of binding a value to a name).

> Surely that means that if I misspell a variable name, my program will
> mysteriously fail to work with no error message.

Depends. If you try to use an undefined variable, you'll get a name error:

>>> print var1 # var1 is undefined at this stage
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
NameError: name 'var1' is not defined

Now if the typo is on the LHS, you'll just create a new name in the
current namespace:

myvra = 42 # should have been 'myvar' and not 'myvra'

But you'll usually discover it pretty soon:

print myvar
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
NameError: name 'myvar' is not defined


> If you don't declare variables, you can inadvertently re-use an
> variable used in an enclosing context when you don't intend to,

yes, but this is quite uncommon.

The 'enclosing context' is composed of the 'global' (which should be
named 'module') namespace and the local namespace. Using globals is bad
style, so it shouldn't be too much of a concern, but anyway trying to
*assign* to a var living in the global namespace without having
previously declared the name as global will not overwrite the global
variable - only create a local name that'll shadow the global one. Since
Python is very expressive, functions code tend to be small, so the
chances of inadvertently reuse a local name are usually pretty low.

Now we have the problem of shadowing inherited attributes in OO. But
then the same problem exists in most statically typed OOPLs.

> or
> inadvertently reference a new variable (a typo) when you intended to
> reference an existing variable.

Nope. Trying to 'reference' an undefined name raises a name error.

> What can one do to swiftly detect this type of bug?

1/ write small, well-decoupled code
2/ use pychecker or pylint
3/ write unit tests

You'll probably find - as I did - that this combination (dynamic typing
+ [pylint|pychecker] + unit tests) usually leads to fewer bugs than just
relying on declarative static typing.

What you fear can become reality with some (poorly designed IMHO)
scripting languages like PHP, but should not be a concern with Python.
Try working with it (and not to fight agaisnt it), and you'll see by
yourself if it fits you.

-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb at xiludom.gro'.split('@')])"