paul@153 | 1 | Namespace Definition
|
paul@153 | 2 | ====================
|
paul@153 | 3 |
|
paul@153 | 4 | Module attributes are defined either at the module level or by global
|
paul@153 | 5 | statements.
|
paul@153 | 6 |
|
paul@153 | 7 | Class attributes are defined only within class statements.
|
paul@153 | 8 |
|
paul@153 | 9 | Instance attributes are defined only by assignments to attributes of self
|
paul@153 | 10 | within __init__ methods.
|
paul@153 | 11 |
|
paul@153 | 12 | (These restrictions apply because such attributes are thus explicitly
|
paul@153 | 13 | declared. Module and class attributes can also be finalised in this way in
|
paul@153 | 14 | order to permit certain optimisations.)
|
paul@153 | 15 |
|
paul@153 | 16 | Potential Restrictions
|
paul@153 | 17 | ----------------------
|
paul@153 | 18 |
|
paul@153 | 19 | Names of classes and functions could be restricted to only refer to those
|
paul@153 | 20 | objects within the same namespace. If redefinition were to occur, or if
|
paul@153 | 21 | multiple possibilities were present, these restrictions could be moderated as
|
paul@153 | 22 | follows:
|
paul@153 | 23 |
|
paul@153 | 24 | * Classes assigned to the same name could provide the union of their
|
paul@153 | 25 | attributes. This would, however, cause a potential collision of attribute
|
paul@153 | 26 | definitions such as methods.
|
paul@153 | 27 |
|
paul@153 | 28 | * Functions, if they share compatible signatures, could share parameter list
|
paul@153 | 29 | definitions.
|
paul@153 | 30 |
|
paul@153 | 31 | It is easier, however, to regard multiply defined classes and functions as
|
paul@153 | 32 | non-constant and to either disallow optimisations or to actually prevent the
|
paul@153 | 33 | program describing them from compiling.
|