Deprecate pickle support for itertools

[rhettinger]

Pickle support was long ago added to some itertools. It was done mostly to support an atypical use case for a single company. It was implemented in a very inefficient manner, essentially replaying iteration from the beginning to the mid-stream state where it was frozen. The implementation was of low quality and had many bugs. Also, it was not a documented or advertised feature. Newer itertools don't support pickling and no one has noticed or cared. The popular third-party package more-itertools is implemented with generators which do not have pickle support — again, none of their users seems to have noticed or cared.

IMO, this is just cruft that has made maintenance more difficult and we should get rid of it. As an undocumented feature, we could just remove it directly. But to be on the safe side, we can go through a deprecation cycle.

Linked PRs

• GH-101588: Deprecate pickle/copy/deepcopy support in itertools #104965
• [3.12] GH-101588: Deprecate pickle/copy/deepcopy support in itertools (GH-104965) #104997
• GH-101588: Remove deprecated pickle/copy/deepcopy from itertools #118816

[JosephSBoyle]

Hi @rhettinger, would you like a hand on this?

[ZackerySpytz]

@JosephSBoyle I am already working on a patch for this issue. Please find a different issue to work on.

[rhettinger]

Thanks for working on this. When the PR is ready for review, please assign to me :-)

[rhettinger]

@JosephSBoyle Do you pick up this task?

[ZackerySpytz]

I still plan to create a pull request for this issue (within the next two weeks, hopefully).

[JosephSBoyle]

Hi @rhettinger, I'd be happy to work on this.

@ZackerySpytz, perhaps we could work together somehow? Up to you - I appreciate that you were working on this before I volunteered to help.

[Gouvernathor]

I was about to use the pickling feature on my end, and I wouldn't have noticed this had I not checked in the doc, noticed it wasn't there and propose it to be in the issue above.
So, I wouldn't be surprised if others than me use the feature as well, and while I fully understand and support the rationale for deprecating, I think making it follow a deprecation cycle wouldn't hurt.
In my experience and opinion, iterators in python generally fail spectacularly when you try to pickle them, so having the itertools one not fail may have felt for many to be a low-key guarantee on that being a supported feature, even if it was not explicitly documented (and even though it's not a very good practice).

[rhettinger]

@JosephSBoyle You no longer need to wait. There is no particular reason for @ZackerySpytz to reserve this one. There are plenty of other open bugs.

[JosephSBoyle]

Sure, @rhettinger. Where would you recommend starting on this?

[rhettinger]

Thomas, can this deprecation still go into 3.12? It deprecates an undocumented feature.

[Yhg1s]

It may be undocumented but pickle use is so viral, it's very likely depended on without people even knowing :) Let's get the deprecation into beta 2 if we can (it's scheduled for next week), but given that it's not actually problematic and just something we don't want to support, I would suggest holding back on removing it until we have a clearer picture of what it would break.

[serhiy-storchaka]

I missed when this was deprecated, but I support this. It was inefficient, it leaked internal state, and it often not worked as expected for complex iterators like chain or tee.

Should not this also be deprecated for builtins zip, map and filter, and for iterators of builtin collections?