-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
PEP 784: Mark as Accepted #4387
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
base: main
Are you sure you want to change the base?
Conversation
As requested by the Steering Council
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.
Two questions.
Assuming the Council is happy with the text, please also include the relevant changes to the headers in this PR, and update the title appropriately.
A
documentation for existing modules will be updated to reference the new names | ||
as well. |
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.
Do the new names now become canonical? The PEP should take a position.
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.
I think yes the new names should become canonical. Let's see what other SC members think.
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.
The intent is for them to become canonical as that is why the compression namespaces is useful. I expect we may iterate on how exactly to present this in our docs outside the PEP.
As far as the text in the PEP goes adding something along the lines of:
"The use of the new compression names will be promoted over the original top level module names in the Python documentation when the users minimum Python version support requirements makes that feasible."
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.
I added a sentence about this in 53ab0b5. Not sure if I should be stronger in my wording but hopefully that clearly makes a stance.
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.
Oh, my page was open from last night and I missed Greg's comment. I'll include that text.
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.
Added in 9d58ebc, I made a slight edit to the sentence to clarify, hopefully that's ok!
(adding the label as this PR requires governance approval) |
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.
With the one suggestion, this LGTM, but let's give time for the other @python/steering-council members to weigh in.
Co-authored-by: Barry Warsaw <[email protected]>
Co-authored-by: Adam Turner <[email protected]>
Co-authored-by: "Gregory P. Smith" <[email protected]>
Discussions-To
threadPEP 123: Mark as Accepted
)Status
changed toAccepted
/Rejected
Resolution
field points directly to SC/PEP Delegate official acceptance/rejected post, including the date (e.g.`01-Jan-2000 <https://discuss.python.org/t/12345/100>`__
)Discussions-To
,Post-History
andPython-Version
up to dateI removed any references to removal or deprecation of the existing modules other than to say that it is left to a future decision as part of the Backwards Compatibility section.
At the behest of Barry, cc'ing @python/steering-council to review the exact language.
📚 Documentation preview 📚: https://pep-previews--4387.org.readthedocs.build/