paul@283 | 1 | Code Generation and Optimisation Issues
|
paul@283 | 2 | =======================================
|
paul@283 | 3 |
|
paul@283 | 4 | Python's dynamic nature provides a few issues which obstruct the generation of
|
paul@283 | 5 | optimised code.
|
paul@283 | 6 |
|
paul@283 | 7 | Attribute and Method Selection
|
paul@283 | 8 | ------------------------------
|
paul@283 | 9 |
|
paul@283 | 10 | Python provides a kind of shadowing of attributes so that objects which do not
|
paul@283 | 11 | provide a particular attribute can still appear to provide such an attribute
|
paul@283 | 12 | via the object's class or base classes. If access via the object or the class
|
paul@283 | 13 | are both possible for a particular case, two different kinds of access would
|
paul@283 | 14 | need to be provided at that location in the program.
|
paul@283 | 15 |
|
paul@283 | 16 | Unlike other languages, methods and non-method attributes are interchangeable
|
paul@283 | 17 | and are provided by objects or classes. Consequently, distinctions between
|
paul@283 | 18 | attributes and methods, with special rules for method selection (virtual vs.
|
paul@283 | 19 | non-virtual) do not exist. Moreover, unlike some languages such as C++ where
|
paul@283 | 20 | explicit qualification of an object's type can be used to reference an
|
paul@283 | 21 | attribute - for example, by saying that an object is of type X, an attribute
|
paul@283 | 22 | can be located using knowledge of the structure of instances of X - such
|
paul@283 | 23 | qualification does not take place in Python programs, and such knowledge must
|
paul@283 | 24 | be provided by other means.
|
paul@283 | 25 |
|
paul@283 | 26 | Parameter Structures
|
paul@283 | 27 | --------------------
|
paul@283 | 28 |
|
paul@283 | 29 | Python provides some complicated ways of passing parameters to functions and
|
paul@283 | 30 | methods, such as keyword arguments and "overflow" parameters (star and dstar
|
paul@283 | 31 | parameters). Consequently, if parameter values are to be put on a stack and
|
paul@283 | 32 | given to a function, resolution of keyword arguments and "excess" arguments
|
paul@283 | 33 | (of both positional and keyword varieties) must take place. This is made even
|
paul@283 | 34 | more complicated by the possibility that at a given invocation site, many
|
paul@283 | 35 | potentially incompatible functions may be called, each with their own optimal
|
paul@283 | 36 | parameter ordering.
|