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.svet...@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 <m...@hotpy.org> wrote: >> Andrew Svetlov wrote: >>> >>> Do you want to create `frame` and `f_namespaces` 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 <m...@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 f_yieldfrom field from the frame object. >>>> (http://bugs.python.org/issue14230) >>>> >>>> The f_exc_type, f->f_exc_value, f->f_exc_traceback fields which handle >>>> sys.exc_info() in generators could be moved to the generator object. >>>> (http://bugs.python.org/issue13897) >>>> >>>> The f_tstate field is redundant and, it would seem, dangerous >>>> (http://bugs.python.org/issue14432) >>>> >>>> The f_builtins, f_globals, f_locals fields could be combined into a >>>> single f_namespaces 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@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@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
