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

Andrew Svetlov andrew.svetlov at gmail.com
Mon Apr 9 15:02:50 CEST 2012

While I agree with keeping data structures simple and clean I think conserving them forever is bad idea in general. Let's look on every particular case before making decision.

On Mon, Apr 9, 2012 at 3:46 PM, Andrew Svetlov <andrew.svetlov at gmail.com> wrote:

So it's really no difference between three separate fields in frame and embedded struct with those fields.

On Mon, Apr 9, 2012 at 1:51 PM, Mark Shannon <mark at hotpy.org> wrote: Andrew Svetlov wrote:

Do you want to create frame and fnamespaces every function call instead of single frame creation? fnamespaces would be part of the frame, replacing fbuiltins, fglobals and flocals. 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

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 -- Thanks, Andrew Svetlov

-- Thanks, Andrew Svetlov

More information about the Python-Dev mailing list