What's the pythonic way of declaring variables?

Question

Usually declaring variables on assignment is considered a best practice in VBScript or JavaScript , for example, although it is allowed.

Why does Python force you to create the variable only when you use it? Since Python is case sensitive can't it cause bugs because you misspelled a variable's name?

How would you avoid such a situation?

Answer 1

In python it helps to think of declaring variables as binding values to names.

Try not to misspell them, or you will have new ones (assuming you are talking about assignment statements - referencing them will cause an exception).

If you are talking about instance variables, you won't be able to use them afterwards.

For example, if you had a class myclass and in its __init__ method wrote self.myvar = 0, then trying to reference self.myvare will cause an error, rather than give you a default value.

Answer 2

Python never forces you to create a variable only when you use it. You can always bind None to a name and then use the name elsewhere later.

Answer 3

If you do any serious development you'll use a (integrated) development environment. Pylint will be part of it and tell you all your misspellings. No need to make such a feature part of the langauge.

Answer 4

To avoid a situation with misspelling variable names, I use a text-editor with an autocompletion function and binded

 python -c "import py_compile; py_compile.compile('{filename}')"

to a function to be called when I save a file.

Answer 5

Test.

Example, with file variable.py:

#! /usr/bin/python

somevar = 5

Then, make file variable.txt (to hold the tests):

>>> import variables
>>> variables.somevar == 4
True

Then do:

python -m doctest variable.txt

And get:

**********************************************************************
File "variables.txt", line 2, in variables.test
Failed example:
    variables.somevar == 4
Expected:
    True
Got:
    False
**********************************************************************
1 items had failures:
   1 of   2 in variables.test
***Test Failed*** 1 failures.

This shows a variable declared incorrectly.

Try:

>>> import variables
>>> variables.someothervar == 5
True

Note that the variable is not named the same.

**********************************************************************
File "variables.test", line 2, in variables.test
Failed example:
    variables.someothervar == 5
Exception raised:
    Traceback (most recent call last):
      File "/usr/local/lib/python2.6/doctest.py", line 1241, in __run
        compileflags, 1) in test.globs
      File "<doctest variables.test[1]>", line 1, in <module>
        variables.someothervar == 5
    AttributeError: 'module' object has no attribute 'someothervar'
**********************************************************************
1 items had failures:
   1 of   2 in variables.test
***Test Failed*** 1 failures.

This shows a misspelled variable.

>>> import variables
>>> variables.somevar == 5
True

And this returns with no error.

I've done enough VBScript development to know that typos are a problem in variable name, and enough VBScript development to know that Option Explicit is a crutch at best. (<- 12 years of ASP VBScript experience taught me that the hard way.)

Answer 6

It's a silly artifact of Python's inspiration by "teaching languages", and it serves to make the language more accessible by removing the stumbling block of "declaration" entirely. For whatever reason (probably represented as "simplicity"), Python never gained an optional stricture like VB's "Option Explicit" to introduce mandatory declarations. Yes, it can be a source of bugs, but as the other answers here demonstrate, good coders can develop habits that allow them to compensate for pretty much any shortcoming in the language -- and as shortcomings go, this is a pretty minor one.

Answer 7

If you want a class with "locked-down" instance attributes, it's not hard to make one, e.g.:

class LockedDown(object):
  __locked = False
  def __setattr__(self, name, value):
    if self.__locked:
      if name[:2] != '__' and name not in self.__dict__:
        raise ValueError("Can't set attribute %r" % name)
    object.__setattr__(self, name, value)
  def _dolock(self):
    self.__locked = True

class Example(LockedDown):
  def __init__(self):
    self.mistakes = 0
    self._dolock()
  def onemore(self):
    self.mistakes += 1
    print self.mistakes
  def reset(self):
    self.mitsakes = 0

x = Example()
for i in range(3): x.onemore()
x.reset()

As you'll see, the calls to x.onemore work just fine, but reset raises an exception because of the mis-spelling of the attribute as mitsakes. The rules of engagement here are that __init__ must set all attributes to initial values, then call self._dolock() to forbid any further addition of attributes. I'm exempting "super-private" attributes (ones starting with __), which stylistically should be used very rarely, for totally specific roles, and with extremely limited scope (making it trivial to spot typos in the super-careful inspection that's needed anyway to confirm the need for super-privacy), but that's a stylistic choice, easy to reverse; similarly for the choice to make the locked-down state "irreversible" (by "normal" means -- i.e. requiring very explicit workaround to bypass).

This doesn't apply to other kinds of names, such as function-local ones; again, no big deal because each function should be very small, and is a totally self-contained scope, trivially easy to inspect (if you write 100-lines functions, you have other, serious problems;-).

Is this worth the bother? No, because semi-decent unit tests should obviously catch all such typos with the greatest of ease, as a natural side effect of thoroughly exercising the class's functionality. In other words, it's not as if you need to have more unit tests just to catch the typos: the unit tests you need anyway to catch trivial semantic errors (off-by-one, +1 where -1 is meant, etc., etc.) will already catch all typos, too.

Robert Martin and Bruce Eckel both articulated this point 7 years ago in separate and independent articles -- Eckel's blog is temporarily down right now, but Martin's right here, and when Eckel's site revives the article should be here. The thesis is controversial (Jeff Attwood and his commenters debate it here, for example), but it's interesting to note that Martin and Eckel are both well-known experts of static languages such as C++ and Java (albeit with love affairs, respectively, with Ruby and Python), and they're far from the only ones to have discovered the importance of unit-tests... and how a good unit-tests suite, as a side effect, makes a static language's rigidity redundant.

By the way, one way to check your test suites is "error injection": systematically go over your codebase introducing one mis-spelling -- run the tests to make sure they do fail, if they don't add one that does fail, correct the spelling mistake, repeat. Can be fairly well automated (not the "add a test" part, but the finding of potential errors that aren't covered by the suite), as can some other forms of error injections (change every integer constant, one by one, to one more, and to one less; change each < to <= etc; swap each if and while condition to its reverse; ...), while other forms of error-injection yet require a lot more human savvy. Unfortunately I don't know of publicly available suites of error injection frameworks (for any language) -- might make a cool open source project;-).

Answer 8

Variable declaration does not prevent bugs. Any more than lack of variable declaration causes bugs.

Variable declarations prevent one specific type of bug, but it creates other types bugs.

Prevent. Writing code where there's an attempt to set (or change) a variable with the wrong type of data.

Causes. Stupid workarounds to coerce a number of unrelated types together so that assignments will "just work". Example: The C language union. Also, variable declarations force us to use casts. Which also forces us to suppress warnings on casts at compile time because we "know" it will "just work". And it doesn't.

Lack of variable declarations does not cause bugs. The most common "threat scenario" is some kind of "mis-assignment" to a variable.

1. Was the variable being "reused"? This is dumb but legal and works.

2. Was some part of the program incorrectly assigning the wrong type?

   That leads to a subtle question of "what does wrong mean?" In a duck-typed language, wrong means "Doesn't offer the right methods or attributes." Which is still nebulous. Specifically, it means "the type will be asked to provide a method or attribute it doesn't have." Which will raise an exception and the program will stop.

Raising an uncaught exception in production use is annoying and shows a lack of quality. It's stupid, but it's also a detected, known failure mode with a traceback to the exact root cause.

"can't it cause bugs because you misspelled a variable's name"

Yes. It can.

But consider this Java code.

public static void maine( String[] argv ) {
    int main;
    int mian;
}

A misspelling here is equally fatal. Statically typed Java has done nothing to prevent a misspelled variable name from causing a bug.