This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients belopolsky, berker.peksag, bmispelon, corona10, p-ganssle, rhettinger, serhiy.storchaka, taleinat, tim.peters, vstinner
Date 2019-09-04.12:28:22
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1567600102.96.0.167085836132.issue24416@roundup.psfhosted.org>
In-reply-to
Content
The main blocker issue (if we decide to accept this feature) is the pickle serialization issue.


Serhiy Storchaka:
> No, it is not fully backwards-compatible. First, if pickle a namedtuple, it can't be unpickled in previous versions.

Would it be possible to tell pickle to serialize .isocalendar() as a tuple, and deserialize it from a tuple to a structseq? I'm thinking at __getstate__ and __setstate__ methods, but I'm not sure how to use them.


Serhiy Storchaka:
> Second, namedtuple is slower and larger than tuple, so it shouldn't be used in memory or performance critical code.

vstinner@apu$ python3
Python 3.7.4 (default, Jul  9 2019, 16:32:37) 
>>> import sys
>>> s=sys.version_info
>>> t=tuple(s)
>>> sys.getsizeof(t), sys.getsizeof(s)
(96, 96)
>>> type(s)
<class 'sys.version_info'>

Hum, structseq and tuple seem to have exactly the same memory footprint: only the type is larger, not instances.

According to msg350986, the performance to instanciate a new object is exactly the same between tuple and structseq.
History
Date User Action Args
2019-09-04 12:28:23vstinnersetrecipients: + vstinner, tim.peters, rhettinger, belopolsky, taleinat, berker.peksag, serhiy.storchaka, bmispelon, p-ganssle, corona10
2019-09-04 12:28:22vstinnersetmessageid: <1567600102.96.0.167085836132.issue24416@roundup.psfhosted.org>
2019-09-04 12:28:22vstinnerlinkissue24416 messages
2019-09-04 12:28:22vstinnercreate