CLPython: Implementation Notes
This page lists CLPython deviations from CPython with respect to:
Built-in functions
(See also Built-in function status.)
__import__
Function __import__ is not yet implemented; the function is not called for import statements.
ToDo?: implement it.
eval
Function eval is implemented, but by default CLPython does not allow calling eval indirectly without supplying the argument for locals (e.g. e = eval; e()). (See the discussion for locals.) To enable it, *allow-indirect-special-calls* must be t at the time the Python code is compiled.
globals
By default, CLPython does not allow calling globals indirectly. (See the discussion for locals.) To enable it, *allow-indirect-special-calls* must be t at the time the Python code is compiled.
id
In both CPython and CLPython, the value by id is "unique", in the sense that at any moment two different objects can not have the same id.
While in CPython the id of an object is constant over its lifetime, in CLPython it can change over time. Concretely, id returns the memory location of the object, and that location can change due to garbage collection.
This is a minor difference, and as id is mostly used for explaining object identity and equality, this seems not worth changing.
locals
The function locals is a special one, as it must have access to the local variables of the scope in which it is called.
To implement full Python semantics, for every call (e.g. f(), x.g(), h(*args)) there should be a test whether the object being called (f, x.g, h) is function locals: if so, a dict of the local variables must be returned; and if not, the regular call should take place. This check, though itself cheap, must be done for all calls all the time, and this impacts performance. At the same time, there seem to be hardly any cases where locals is called in another way than simply locals().
For these reason, by default CLPython does not support calling locals indirectly (e.g. using f = locals; f()); all calls to locals must take the form locals().
To enable calling locals indirectly, *allow-indirect-special-calls* must be t at the time the Python code is compiled.
repr
The default string representation of objects takes the form "#<C @ #x120fbe0a>" in CLPython, as created by print-unreadable-object. The CPython representation is currently "<__main__.C instance at 0x5aa58>", though it changes sometimes.
ToDo?: make it possible to obtain CPython behaviour.
Built-in constants
(See also Built-in constants status.)
True and False
In CPython, True and False behave like integers 1 and 0, but have a special status, being instances of class bool. For example, they are printed as "True" or "False". They lose their special status as soon as any operation is done on it; e.g. "True + 0" prints as "1", and "True + True" as "2".
In CLPython True and False are defined as the integers 1 and 0; they will never be printed as "True" or "False" or otherwise be different from normal integers with the same value.
It seems not worth the effort to fix this.
