I was expected the announcement of a BDFL delegate for PEP 657, as the author is a steering council member.
Just to clarify this: as I was the author I didn't get to vote on the approval or rejection of the PEP. Also, there is nowhere that I know where this situation requires a BDFL delegate like you claim.
It seems that a PEP submitted by a SC member has been accepted by the SC with seemingly no external review.
That is very not true. We have added ton of beedback for at least 2 python-dev threads and a discourse thread: * https://discuss.python.org/t/pep-657-include-fine-grained-error-locations-in... * https://mail.python.org/archives/list/python-dev@python.org/thread/DB3RTYBF2... * https://mail.python.org/archives/list/python-dev@python.org/thread/KR7ACFCUN... The design has been iterated many times and we have draft implementations from some of the alternative ideas as the ones proposed by Nathaniel.
interact poorly with debugging and profiling.
"interact poorly with debugging and profiling." is making unfounded claims,
which is especially bad for a feature that is supposed to aid debugging.
You mentioned your worries on
https://mail.python.org/archives/list/python-dev@python.org/thread/KR7ACFCUN...
and we answered them.
Kind regards,
Pablo
On Tue, 29 Jun 2021 at 16:30, Mark Shannon
Hi,
I was expected the announcement of a BDFL delegate for PEP 657, as the author is a steering council member.
It seems that a PEP submitted by a SC member has been accepted by the SC with seemingly no external review.
PEP 657 is likely to cause significant worsening of start up time and interact poorly with debugging and profiling.
Cheers, Mark. _______________________________________________ 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/OPTIO7SW... Code of Conduct: http://python.org/psf/codeofconduct/