Add Python version since deprecation in base64 methods.

[Carreau]

Allow developers to not have to either test on N Python versions or
looked through multiple versions of the docs to know whether they can
easily update.

[berkerpeksag]

3.1 basically means it has been deprecated since the beginning of Python 3 (3.0 wasn't a production quality release) I don't think mentioning an ancient Python 3 version would improve anything.

[zware]

@berkerpeksag I think the point may be to clarify that they have always been deprecated (in Python 3). I'd suggest that we could remove the mention of the deprecated aliases from the docs and keep the added version information in the warnings. If they're not necessary for 2/3 compatibility (I haven't checked), I'd say we can just remove them by now.

[berkerpeksag]

I think they are still in stdlib because of 2/3 compatibility :) I won't object changing the docs to:

.. deprecated:: 3.1 ``encodestring`` is a deprecated alias.

But I'm -1 for changing the deprecation warning. I only found five instances where we added version information in the whole stdlib and it would be nice keep them short.

[Carreau]

3.1 basically means it has been deprecated since the beginning of Python 3 (3.0 wasn't a production quality release) I don't think mentioning an ancient Python 3 version would improve anything.

I think the point may be to clarify that they have always been deprecated (in Python 3)

Yes, thanks for precising, sorry if it was unclear. I agree that the 3.1/3 distinction does not import much, I can change to 3 if you think it is better. But indeed, adding the version number is to have a clear message as to when developpers can be expected to use Xbytes / Drop Xstring.

I'd suggest that we could remove the mention of the deprecated aliases from the docs and keep the added version information in the warnings. If they're not necessary for 2/3 compatibility (I haven't checked), I'd say we can just remove them by now.

I would remove the aliases from the doc as well, but I'm sure some other people may be against that.
You at least want to make sure it's googleable. I can do it if requested.

I won't object changing the docs to: .. deprecated:

Absolutely, I can do that. That's a really good point.

But I'm -1 for changing the deprecation warning. I

Let me try to explain why I think version number since deprecation is a useful addition. If I am developing an application and I see a deprecation warning including the version number in the deprecation warning will be the difference making me decide I need to upgrade because I know all the Python version I support have the new API. And me just ignoring the deprecation warning because I don't have the time to goo fetch the doc, and find the version since deprecation.

I think that giving incentive to people to update from deprecated API is crucial if you want adoption of new APIs.

and it would be nice keep them short.

That's a perfectly valid argument as well "Available since 3.1" might be too much. Would "encodestring() is a deprecated alias since Python 3 use encodebytes()" be short enough for you ?

I appreciate the time you took to respond to me. I'll update the doc accordingly.

Thanks.

[codecov]

Codecov Report

Merging #33 into master will increase coverage by <.01%.
The diff coverage is 0%.

@@ Coverage Diff @@## master #33 +/- ## ========================================== + Coverage 82.37% 82.37% +<.01%  ========================================== Files 1427 1427 Lines 350948 350948 ========================================== + Hits 289091 289095 +4 + Misses 61857 61853 -4

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 649a7ca...ad04ebf. Read the comment docs.

[berkerpeksag]

This looks good to me, thanks! I don't think we need a Misc/NEWS entry for this. @zware what do you think about the last version of the PR?

[Carreau]

Thanks ! Much appreciated !