Skip to content
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

Merged
merged 2 commits into from
Mar 2, 2017

Conversation

Carreau
Copy link
Contributor

@Carreau Carreau commented Feb 12, 2017

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
Copy link
Member

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
Copy link
Member

zware commented Feb 12, 2017

@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
Copy link
Member

berkerpeksag commented Feb 12, 2017

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
Copy link
Contributor Author

Carreau commented Feb 12, 2017

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.

@Carreau Carreau force-pushed the deprecations-base64 branch from 7da0daf to ad04ebf Compare February 13, 2017 04:26
@codecov
Copy link

codecov bot commented Feb 13, 2017

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.

@Carreau Carreau force-pushed the deprecations-base64 branch from ad04ebf to 0fadaa2 Compare February 16, 2017 03:12
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.
@Carreau Carreau force-pushed the deprecations-base64 branch from 0fadaa2 to 1e409fb Compare February 16, 2017 04:09
Copy link
Member

@berkerpeksag berkerpeksag left a 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?

@berkerpeksag berkerpeksag merged commit c643a96 into python:master Mar 2, 2017
@Carreau Carreau deleted the deprecations-base64 branch March 2, 2017 17:34
@Carreau
Copy link
Contributor Author

Carreau commented Mar 2, 2017

Thanks ! Much appreciated !

berkerpeksag pushed a commit to berkerpeksag/cpython that referenced this pull request Mar 3, 2017
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)
berkerpeksag pushed a commit to berkerpeksag/cpython that referenced this pull request Mar 3, 2017
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)
berkerpeksag added a commit that referenced this pull request Mar 3, 2017
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)
berkerpeksag added a commit that referenced this pull request Mar 3, 2017
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)
jaraco pushed a commit to jaraco/cpython that referenced this pull request Feb 17, 2023
"filename" -> "resource"

Closes python#33

See merge request python-devs/importlib_resources!39
jaraco added a commit to jaraco/cpython that referenced this pull request Feb 17, 2023
* 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>
Fidget-Spinner referenced this pull request in pylbbv/pylbbv May 27, 2023
* 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>
oraluben pushed a commit to oraluben/cpython that referenced this pull request Jun 25, 2023
* 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>
nanjekyejoannah pushed a commit to nanjekyejoannah/cpython that referenced this pull request Dec 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants