Revisit IsoCalendarDate being private from pickle perspective

[msimpasona]

BPO	42070
Nosy	@terryjreedy, @abalkin, @pganssle

^{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 = None
closed_at = None
created_at = <Date 2020-10-18.18:44:55.085>
labels = ['type-feature', 'library', '3.10']
title = 'Revisit IsoCalendarDate being private from pickle perspective'
updated_at = <Date 2020-10-24.03:46:18.232>
user = 'https://bugs.python.org/msimpasona'

bugs.python.org fields:

activity = <Date 2020-10-24.03:46:18.232>
actor = 'terry.reedy'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2020-10-18.18:44:55.085>
creator = 'msimpasona'
dependencies = []
files = []
hgrepos = []
issue_num = 42070
keywords = []
message_count = 6.0
messages = ['378884', '378896', '379466', '379480', '379482', '379515']
nosy_count = 4.0
nosy_names = ['terry.reedy', 'belopolsky', 'p-ganssle', 'msimpasona']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue42070'
versions = ['Python 3.10']

[msimpasona]

IsoCalendarDate is pickled as a regular tuple and so requires a slightly different code flow in case the pickle file is used as cache. More details here: https://stackoverflow.com/questions/64408303/python-3-9-unpickling-of-isocalendardate-data-returns-a-tuple

My question is what's the benefit of hiding the new class IsoCalendarDate?

[pganssle]

That's a reasonable enough objection, though what use case do you have for storing the IsocalendarDate object? The main reason we switched to using a named tuple like this was because the vast majority of uses of isocalendar() that I saw were people doing stuff like dt.isocalendar()[0], rather than destructuring the tuple or accessing more than one element from the result.

It seems to me that if you are using a pickle for a cache, you'd either pickle the datetime itself (and call .isocalendar() in the process that has read from the cache already), or you'd store one or more of the fields directly on the object that you are caching.

A real life use case for this would help.

[terryjreedy]

If the current situation is not a bug, a mismatch between behavior and doc, a change would be an enhancement limited to the next release.