-
-
Notifications
You must be signed in to change notification settings - Fork 30.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Python version since deprecation in base64 methods. #33
Conversation
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. |
@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. |
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. |
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 would remove the aliases from the doc as well, but I'm sure some other people may be against that.
Absolutely, I can do that. That's a really good point.
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.
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. |
7da0daf
to
ad04ebf
Compare
Codecov Report
@@ 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.
|
ad04ebf
to
0fadaa2
Compare
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.
0fadaa2
to
1e409fb
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
Thanks ! Much appreciated ! |
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. (cherry picked from commit c643a96)
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. (cherry picked from commit c643a96)
"filename" -> "resource" Closes python#33 See merge request python-devs/importlib_resources!39
* Use `extend-ignore` in flake8 config This option allows to add extra ignored rules to the default list instead of replacing it. The default exclusions are: E121, E123, E126, E226, E24, E704, W503 and W504. Fixes python#28. Refs: * https://github.com/pypa/setuptools/pull/2486/files#r541943356 * https://flake8.pycqa.org/en/latest/user/options.html#cmdoption-flake8-extend-ignore * https://flake8.pycqa.org/en/latest/user/options.html#cmdoption-flake8-ignore * Enable complexity limit. Fixes jaraco/skeleton#34. * Replace pep517.build with build (python#37) * Replace pep517.build with build Resolves python#30 * Prefer simple usage Co-authored-by: Jason R. Coombs <jaraco@jaraco.com> * Use license_files instead of license_file in meta (python#35) Singular `license_file` is deprecated since wheel v0.32.0. Refs: * https://wheel.readthedocs.io/en/stable/news.html * https://wheel.readthedocs.io/en/stable/user_guide.html#including-license-files-in-the-generated-wheel-file Co-authored-by: Jason R. Coombs <jaraco@jaraco.com>
* Added EXTENDED_ARG to type prop * Revert "Added EXTENDED_ARG to type prop" This reverts commit 7249cb7. * Fix: Buggy type propagation across SWP * Fix: Forgot to tag pointers in TYPE_SET * Fix: BB_TEST_ITER wrong type propagation * Fix: Bug in typeprop handling UNPACK_*, and bug in COPY_NO_INCREF * Fix: Misc macro fix * Fix: Ref leak in unboxing checks --------- Co-authored-by: Ken Jin <kenjin@python.org>
* fix: mark interpreter frames as tier 2 or not * Test: Added tests for python#33 --------- Co-authored-by: Ken Jin <28750310+Fidget-Spinner@users.noreply.github.com>
Fix regression
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.