[Python-Dev] Removing surplus fields from the frame object and not adding any new ones. (original) (raw)

Mark Shannon mark at hotpy.org
Mon Apr 9 12:51:54 CEST 2012

Andrew Svetlov wrote:

Do you want to create frame and fnamespaces every function call instead of single frame creation?

f_namespaces would be part of the frame, replacing f_builtins, f_globals and f_locals. The indirection of an external object hurts performance, so it would have to be a struct within the frame. The aim is clarity; locals, globals and builtins form a trio, so should be implemented as such.

On Mon, Apr 9, 2012 at 11:56 AM, Mark Shannon <mark at hotpy.org> wrote:

The frame object is a key object in CPython. It holds the state of a function invocation. Frame objects are allocated, initialised and deallocated at a rapid rate. Each extra field in the frame object requires extra work for each and every function invocation. Fewer fields in the frame object means less overhead for function calls, and cleaner simpler code.

We have recently removed the fyieldfrom field from the frame object. (http://bugs.python.org/issue14230) The fexctype, f->fexcvalue, f->fexctraceback fields which handle sys.excinfo() in generators could be moved to the generator object. (http://bugs.python.org/issue13897) The ftstate field is redundant and, it would seem, dangerous (http://bugs.python.org/issue14432) The fbuiltins, fglobals, flocals fields could be combined into a single fnamespaces struct. (http://code.activestate.com/lists/python-dev/113381/) Now PEP 419 proposes adding (yet) another field to the frame object. Please don't. Clean, concise data structures lead to clean, concise code. which we all know is a "good thing" :) Cheers, Mark.

Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/andrew.svetlov%40gmail.com

More information about the Python-Dev mailing list