Lichen

docs/wiki/Builtins

934:2989aab1b4f7
2021-06-29 Paul Boddie Renamed the utf8string class to unicode, eliminating the unicode function. This means that the simple case of merely returning an object if it is already a Unicode object no longer occurs when using the unicode callable, but such behaviour might be better supported with more general customised instantiation functionality.
     1 = Built-Ins =     2      3 The "built-ins" are a collection of special names that do not need to be     4 explicitly imported. For example:     5      6 {{{#!python numbers=disable     7 biggest = max([23, 19, 27]) # max is a built-in function     8 }}}     9     10 Such names are always available as if they were defined in the current module.    11 However, they are provided by a package hierarchy that seeks to divide them    12 into isolated areas of functionality that can be included or excluded    13 depending on the facilities employed by each program. For example, complex    14 numbers are provided in the `__builtins__.complex` module, but for any program    15 not employing complex numbers, this module will be excluded and its    16 functionality not appear in the final program. (The exclusion of modules is    17 achieved using the hidden module functionality provided by the    18 [[../Imports|import mechanism]].)    19     20 The principal, "top-level" module providing built-ins is the `__builtins__`    21 module whose only role is to expose the actual built-in names. It does so by    22 importing names directly from the different submodules, such as    23 `__builtins__.complex`, so that attempts to import names from `__builtins__`    24 may provide such attempts with the named objects. The `__builtins__` module    25 looks like this in such cases:    26     27 {{{#!python numbers=disable    28 from __builtins__.complex import complex    29 }}}    30     31 Accesses to built-in names use the same technique of importing a name    32 (`complex`) rather than the module providing it (`__builtins__`). It is as if    33 the following code would appear before usage of a built-in name:    34     35 {{{#!python numbers=disable    36 from __builtins__ import complex    37 }}}    38     39 Since it is the specific name that is being referenced, not the module, the    40 other contents of the module can be ignored and the reference to the named    41 object followed to its actual definition location. Thus, usage of `complex`    42 causes `__builtins__.complex` to be included in the program so that it may    43 provide the `complex` type.    44     45 Thus, it becomes possible to keep a module like `__builtins__` out of the    46 program since its only role would be to hold references to other modules'    47 objects, but such specific imports permit the module to be bypassed by just    48 following the declared import relationships. However, consider the    49 consequences of `__builtins__` being imported as follows:    50     51 {{{#!python numbers=disable    52 import __builtins__    53 }}}    54     55 Its entire contents would then need to be exposed because it would then be    56 possible to access any name provided by the module via the module. This was    57 not the case with a specific name import because there was no way of    58 referencing the module itself as a result of such an import.    59     60 This would then cause all of the referenced modules to be imported because it    61 would no longer be possible to readily identify the modules that would    62 actually be needed by the program. For example:    63     64 {{{#!python numbers=disable    65 def get_things(obj):    66     obj.complex    67     obj.function    68     obj.list    69     70 get_things(__builtins__)    71 }}}    72     73 Of course, no module in a program should be referencing the `__builtins__`    74 module by explicitly importing it, anyway. Given that all the names provided    75 by that module are already available without any need to perform an import    76 operation, such an import operation would have rather limited additional    77 benefits.