On Wed., 11 Dec. 2019, 9:16 pm Mark Shannon, <m...@hotpy.org> wrote: > > > 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. >
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. >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/2LNUKNZKPUWQXLHNSQLRB2D6XRKYNXCQ/ Code of Conduct: http://python.org/psf/codeofconduct/
