Christian Tismer added the comment: I would like to make an additional suggestion. (and I implemented this yesterday):
Native namedtuple (not a derived class) can be made much simpler to handle when no module and class machinery is involved at all. The way I implemented it has no need for sys._getframes, and it does not store a reference to the class at all. The advantage of doing so is that this maximizes the compatibility with ordinary tuples. Ordinary tuples have no pickling issue at all, and this way the named tuple should behave as well. My implementation re-creates the namedtuple classes on the fly by a function in __reduce_ex__. There is no speed penalty for this because of caching the classes by their unique name and set of field names. This is IMHO the way things should work: A namedtuple replaces a builtin type, so it has the same pickling behavior: nothing needed. Rationale: tuples are used everywhere and dynamically. namedtuple should be as compatible to that as possible. By having to specify a module etc., this dynamic is partially lost. Limitation: When a class is derived from namedtuple, pickling support is no longer automated. This is compatible with ordinary tuples as well. Cheers - Chris ---------- hgrepos: +198 nosy: +Christian.Tismer _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue17941> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
