Python – Usage of __ While Declaring Variables or Class Members

Yes, you should assign all attributes of your object in the __init__ method.

The most important reason to do this is tool support. Many Python IDEs can see the assignments in the __init__ and use those attributes for type-based autocompletion. Sphinx-doc can list those attributes in your reference documentation.

There's also a more fundamental reason: Simple is good, so don't create complicated objects that change their shape during execution. Given a StringHandler instance I may or may not be able to read the handler.strings attribute. If I try that before handler.parse() has been executed, I will get an AttributeError. Afterwards I would get the value. To avoid exceptions, consumers of your class would have to getattr(handler, 'strings', None) with a default value which is quite tedious.

In general, constructors should create fully-initialized objects that are immediately usable. In some cases it is necessary to create mutable objects that have an empty, default state, and later transition to a state where they contain a value. However, this should be the exception and is rarely a good design. See also Are init() methods a code smell? and Start Method vs. Setting up everything in constructor which discuss this issue for Java.

In your case the parse() method is such a two-phase initialization method that must be called before the object can really be used. This raises the questions:

• What is the point of these objects, if they're just a container for whatever values the parse() function produces? As you are using them, you might as well use a dict instead of a class.

• Is an empty Handler meaningful in any way?

• Why is the initialization in parse() separate from the other initialization?

• Or are you using those attributes only for communication between the parse_x functions, not for external consumers?

Possible alternative designs:

• The handlers specify how a field should be parsed, but do not actually contain the value. The parse method returns the value. Because the handlers do not contain any data, it may not be necessary to use classes for this – simple functions could are sufficient.

• The handlers represent a parsed value. There is no “empty” state. The parsing either happens in the constructor, or in separate functions. Because these objects are just dumb structs, you could define them via namedtuple() when parsing is separate.

This is a mostly stylistic choice. In the end, it doesn't matter. There are some finer differences depending on how they are used.

• If the constants are only used within the module, using module-level variables is more convenient. (Compare class variables below).

• If the constants are used outside of this module, then module-level variables have the advantage that you can import them.

• Class variables have the advantage that they are bundled in that class. This may provide a more convenient interface because you don't have to pass them around individually. For example, the Enum class does this nicely. But in reverse: why would you be bundling them unless they are used together?

Class variables in Python do have some gotchas.

• Python doesn't have true constants, so anyone could reassign them. (To create read-only fields in Python, you must use a property, or more generally: the descriptor protocol).
• These variables can be shadowed by subclasses, or by instance variables.
• The variables can only be accessed through the class or its instances. E.g. to access the URL variable in a method, you have to say Domain.URL or self.URL. Module-level variables can be accessed directly.

In general, Python doesn't force you to stuff everything into a class. You should use this freedom because most variables or functions don't belong into a class. If in doubt, use free variables/functions instead of fields/methods within a class. You can always change your mind later and refactor.