You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
namedtuple should support fully qualified name for more portable pickling #62141
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee='https://github.com/rhettinger'closed_at=<Date2016-09-12.07:19:09.245>created_at=<Date2013-05-09.03:46:56.729>labels= ['type-bug', 'library']
title='namedtuple should support fully qualified name for more portable pickling'updated_at=<Date2016-09-12.07:19:09.243>user='https://bugs.python.org/elibendersky'
Agreed with Eric. We're already modifying PEP-435 to do it that way.
elibendersky commented on May 10, 2013
elibenderskymannequin
MannequinAuthor
More actions
A question that came up while reviewing the new enum code: "module" or "module_name" for this extra argument? The former is shorter, but the latter is more correct in a way.
Module, please. The class attribute is also called __module__ after all.
On Friday, May 10, 2013, Eli Bendersky wrote:
Eli Bendersky added the comment:
A question that came up while reviewing the new enum code: "module" or
"module_name" for this extra argument? The former is shorter, but the
latter is more correct in a way.
Marking this a low priority. I want to see how it pans out for Enums before adding a new parameter to the namedtuple API. Also, I would like to look at the test cases for Enum so I can see how you're writing tests that would fail without this parameter.
I'd like to propose one slight tweak to the patch. (Also to enum.py.)
If no module name was passed and _getframe() fails, can you set the __module__ attribute to something that will cause pickling the object to fail? That would be much better than letting it pickle but then being unable to unpickle it.
(TBH I'm not sure how this should be accomplished, and if it can't, forget that I said it. But it would be nice.)
sbt commented on May 13, 2013
sbtmannequin
Mannequin
More actions
When pickling a class (or instance of a class) there is already a check
that the invariant
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
BreamoreBoy commented on Jun 13, 2014
BreamoreBoymannequin
Mannequin
More actions
Just slipped under the radar?
MojoVampire commented on Jun 14, 2014
MojoVampiremannequin
Mannequin
More actions
I was already thinking of the same solution Christian.Tismer proposed before I reached his post. namedtuples seem cleaner if they naturally act as singletons, so (potentially whether or not pickling is involved) declaring a namedtuple with the same name and fields twice returns the same class. Removes the need to deal with module qualified names, and if pickle can be made to support it, the namedtuple class itself could be pickled uniquely in such a way that it could be recreated by someone else who didn't even have a local definition of the namedtuple, the module that defines it, etc.
Activity
elibendersky commentedon May 9, 2013
[this came up as part of the Enum discussions. Full details in this thread: http://mail.python.org/pipermail/python-dev/2013-May/126076.html]
namedtuple currently uses this code to obtain the __module__ for the class it creates dynamically so that pickling works:
This may not work correctly on all Python implementations, for example IronPython.
To support some way to pickle on all implementations, namedtuple should support a fully qualified name for the class:
If the name is a qualified dotted name, it will be split and the first part becomes the __module__.
sbt commentedon May 9, 2013
That will not work correctly if the module name has a dot in it.
ericvsmith commentedon May 9, 2013
I agree it should work the same as Enum, and I agree it should be possible to supply the module name. But wouldn't it be cleaner as:
rather than:
?
gvanrossum commentedon May 9, 2013
Agreed with Eric. We're already modifying PEP-435 to do it that way.
elibendersky commentedon May 10, 2013
A question that came up while reviewing the new enum code: "module" or "module_name" for this extra argument? The former is shorter, but the latter is more correct in a way.
gvanrossum commentedon May 10, 2013
Module, please. The class attribute is also called __module__ after all.
On Friday, May 10, 2013, Eli Bendersky wrote:
elibendersky commentedon May 10, 2013
On Fri, May 10, 2013 at 7:02 AM, Guido van Rossum <report@bugs.python.org>wrote:
Makes sense. Thanks.
rhettinger commentedon May 13, 2013
Marking this a low priority. I want to see how it pans out for Enums before adding a new parameter to the namedtuple API. Also, I would like to look at the test cases for Enum so I can see how you're writing tests that would fail without this parameter.
gvanrossum commentedon May 13, 2013
I'd like to propose one slight tweak to the patch. (Also to enum.py.)
If no module name was passed and _getframe() fails, can you set the __module__ attribute to something that will cause pickling the object to fail? That would be much better than letting it pickle but then being unable to unpickle it.
(TBH I'm not sure how this should be accomplished, and if it can't, forget that I said it. But it would be nice.)
sbt commentedon May 13, 2013
When pickling a class (or instance of a class) there is already a check
that the invariant
holds.
gvanrossum commentedon May 13, 2013
Great, forget I said anything then.
LGTM to the patch, feel free to commit (with update to Misc/NEWS please).
warsaw commentedon May 13, 2013
LGTM too. Needs test and docs.
ctismer commentedon Jun 11, 2013
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
BreamoreBoy commentedon Jun 13, 2014
Just slipped under the radar?
MojoVampire commentedon Jun 14, 2014
I was already thinking of the same solution Christian.Tismer proposed before I reached his post. namedtuples seem cleaner if they naturally act as singletons, so (potentially whether or not pickling is involved) declaring a namedtuple with the same name and fields twice returns the same class. Removes the need to deal with module qualified names, and if pickle can be made to support it, the namedtuple class itself could be pickled uniquely in such a way that it could be recreated by someone else who didn't even have a local definition of the namedtuple, the module that defines it, etc.
rhettinger commentedon Jun 14, 2014
Nope, I'll get to it before long.
ctismer commentedon Jun 14, 2014
Ok, I almost forgot about this because I thought my idea
was not considered, and wondered if I should keep that code online.
It is still around, and I could put it into an experimental branch
if someone asks for it.
Missing pull-request on python.org.
serhiy-storchaka commentedon May 27, 2015
Pickling qualified names with arbitrary number of dots is supported in 3.4 with protocol 4 and in 3.5 with all protocols (backward compatibly).
python-dev commentedon Sep 12, 2016
New changeset c8851a0ce7ca by Raymond Hettinger in branch 'default':
Issue bpo-17941: Add a *module* parameter to collections.namedtuple()
https://hg.python.org/cpython/rev/c8851a0ce7ca