andrew.svetlov at gmail
Apr 9, 2012, 6:02 AM
Post #5 of 9
(142 views)
Permalink
|
|
Re: Removing surplus fields from the frame object and not adding any new ones.
[In reply to]
|
|
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> 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> 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 <mark [at] hotpy> 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 [at] python
>>>> 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
>> 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 [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com
|
