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?

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.

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.

Even if it were accidental (and it wasn't — it was actually somewhat difficult to achieve), I'd still argue for not changing it in 3.9, because it would mean that pickles created in 3.9.(n+1) would not be readable in 3.9.n.

Still, I don't think I'd be convinced without some real-life use cases. The SO question is asking about the reasoning for this in the abstract — the poster noticed that we designed it this way and saw a possible objection to this, but it was one that we had considered and decided to make the trade-off a different way.

I informally asked many people about this, since it was by far the weirdest design decision made in that issue (I say that in the passive tense not to deflect from the fact that I made the decision, but to own the fact that it was weirder than any of the design decisions made by anyone else, either 😛), and generally they could not give me any concrete reasons it would break (but they also all counseled not to try to get too clever with pickling logic).

I think I'm happy with the decision if we remain in the realm of the abstract, but I recognize how weird it is, and I think if someone came up with a compelling workflow that this breaks, we could change it (in a feature release). This was specifically proposed to avoid backwards-compatibility problems, so it wouldn't be any more of a breakage to change it in future feature releases than it would have been to do it in 3.9.

I'm glad that Terry brought up documentation, though, because I realized that this is not a documented behavior: https://docs.python.org/3/library/datetime.html#datetime.date.isocalendar

We should maybe document it? Though if we document it it might be considered more of a breaking change to change the behavior than if it's an undocumented feature.

If this point I suggest asking on pydev, maybe after you think more about how you want it to be for the next decade.

If the behavior is intentional and the doc says nothing, one might consider the behavior the 'document'.  Hence deprecation might be needed.  Too bad the API was not labelled 'provisional'.

If not being documented is what lead to the SO question, then it probably should be documented.