Feedback on PEP 611 (so far) from the Steering Council
The Python Steering Council discussed PEP 611 at today’s meeting. Here is our feedback so far: * The Steering Council reserves the right to be the BDFL-Delegate for this PEP * The PEP should clearly delineate two aspects: - A language generic part (i.e. applies to all implementations of Python) which exposes implementation limits in a way that Python code can read at runtime. Think sys.getrecursionlimit(), sys.maxsize, and sys.implementation - An implementation-specific part where the PEP would propose specific limits for the CPython implementation. Other implementations of the Python language would be free to adjust such limits up or down as they deem appropriate. * We encourage the PEP authors and proponents to gather actual performance data that can be used to help us evaluate whether this PEP is a good idea or not. By all means, continue to discuss and refine the PEP. When the PEP author is ready for a pronouncement, you can email the Steering Council. Cheers, -Barry
On 11/12/2019 12:04 am, Barry Warsaw wrote:
The Python Steering Council discussed PEP 611 at today’s meeting. Here is our feedback so far:
* The Steering Council reserves the right to be the BDFL-Delegate for this PEP
* The PEP should clearly delineate two aspects:
- A language generic part (i.e. applies to all implementations of Python) which exposes implementation limits in a way that Python code can read at runtime. Think sys.getrecursionlimit(), sys.maxsize, and sys.implementation
- An implementation-specific part where the PEP would propose specific limits for the CPython implementation. Other implementations of the Python language would be free to adjust such limits up or down as they deem appropriate.
* We encourage the PEP authors and proponents to gather actual performance data that can be used to help us evaluate whether this PEP is a good idea or not.
I think that judging this on numbers from a handful of optimizations would be a mistake. There are an infinite number of potential optimizations, so it is impossible to put numbers on as yet undiscovered optimization. Conversely it is impossible to perfectly predict what limits might restrict possible future applications. Having said that, I agree that it would be useful to come up with example optimizations and applications that benefit or suffer from the limits.
By all means, continue to discuss and refine the PEP. When the PEP author is ready for a pronouncement, you can email the Steering Council.
I welcome more discussion. Ultimately this is a subjective judgement, so the more opinions we have, the better.
Cheers, -Barry
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/KY46EXGL... Code of Conduct: http://python.org/psf/codeofconduct/
On Wed., 11 Dec. 2019, 9:16 pm Mark Shannon, <mark@hotpy.org> wrote:
The Python Steering Council discussed PEP 611 at today’s meeting. Here is our feedback so far:
* The Steering Council reserves the right to be the BDFL-Delegate for
On 11/12/2019 12:04 am, Barry Warsaw wrote: this PEP
* The PEP should clearly delineate two aspects:
- A language generic part (i.e. applies to all implementations of
Python) which exposes implementation limits in a way that Python code can read at runtime. Think sys.getrecursionlimit(), sys.maxsize, and sys.implementation
- An implementation-specific part where the PEP would propose
specific limits for the CPython implementation. Other implementations of the Python language would be free to adjust such limits up or down as they deem appropriate.
* We encourage the PEP authors and proponents to gather actual
performance data that can be used to help us evaluate whether this PEP is a good idea or not.
I think that judging this on numbers from a handful of optimizations would be a mistake.
There are an infinite number of potential optimizations, so it is impossible to put numbers on as yet undiscovered optimization. Conversely it is impossible to perfectly predict what limits might restrict possible future applications.
It is however likely possible to document and expose at runtime the existing limits, regardless of what they may be. Thus the suggestion in Barry's post to separate the two activities of "define and expose the limits" and "potentially lower the limits in CPython specifically". Cheers, Nick.
participants (3)
-
Barry Warsaw -
Mark Shannon -
Nick Coghlan