[Python-ideas] Allow function __globals__ to be arbitrary mapping not just dict
Terry Reedy
tjreedy at udel.edu
Tue Mar 20 03:37:54 CET 2012
On 3/19/2012 7:51 PM, Steven D'Aprano wrote:
> Terry Reedy wrote:
>> On 3/18/2012 8:27 AM, Steven D'Aprano wrote:
>>> Currently, if you try to construct a function from parts, the mapping
>>> that becomes func.__globals__ must be an actual dict:
> [...]
>> The API of internal classes is intentionally not documented in the
>> types module doc. I take this to mean that the api, if not the
>> existence, of such classes, is implementation specific. Hence any such
>> call is a 'cpython' rather than generic python call.
>
> Are you sure that they are *intentionally* not documented, or merely
> haven't been due to lack of time and interest?
100% absolutely sure, no. 90% fairly sure, yes. Less that half of the
internal types even *are* Python-level callables with Python-object
APIs: FunctionType, CodeType, MethodType, ModuleType. The rest are not.
I think there once may have been a discussion of how much to expose
them. While the last two are trivial, the help for CodeType says "Not
for the faint of heart." I suspect that some of these accessible APIs
are new since 1.3, or may have changed. It is hard to know since they
are not documented ;-).
> The types themselves are documented as public, they aren't given _single
> underscore private names,
The module says, "Typical use is for isinstance() or issubclass() checks."
Exposing the internal types was done to do once and do correctly things
that people did (and sometimes still do) in their code, such as
isinstance(f, type(lambda: None)).
The module has similar code to get the types.
def _f(): pass
FunctionType = type(_f)
LambdaType = type(lambda: None) # Same as FunctionType
CodeType = type(_f.__code__)
So there is not way for the objects themselves to not be public. The
names bound to them in types are not their .__name__ attributes. It is
certainly intentional that they are not bound to their names in builtins.
Getting traceback and frame types is trickier to get right:
try:
raise TypeError
except TypeError:
tb = sys.exc_info()[2]
TracebackType = type(tb)
FrameType = type(tb.tb_frame)
tb = None; del tb
> and FunctionType has a minimal but useful doc
> string with nothing about it being implementation specific.
Marking *anything* other than ref-counting and gc behavior as
implementation specific in the docs is fairly recent. The same goes for
cpython-only tests in the test suite. Some of this splitting has been
prompted by questions from Iron-py and pypy developers.
--
Terry Jan Reedy
More information about the Python-ideas
mailing list