Is it too late to critique PEP 657? (Include Fine Grained Error Locations in Tracebacks)
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.
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 <mark@hotpy.org> wrote:
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/
Also, regarding startup times. Here are our benchmarks, measured with Linux perf (https://perf.wiki.kernel.org/index.php/Main_Page) * Importing all the standard library without PEP 657: Performance counter stats for './python import_all_stdlib.py' (500 runs): 303,78 msec task-clock # 0,999 CPUs utilized ( +- 0,05% ) 4 context-switches # 0,014 K/sec ( +- 6,33% ) 0 cpu-migrations # 0,000 K/sec 7.602 page-faults # 0,025 M/sec ( +- 0,05% ) 1.146.643.923 cycles # 3,775 GHz ( +- 0,03% ) 1.613.882.354 instructions # 1,41 insn per cycle ( +- 0,01% ) 391.399.735 branches # 1288,440 M/sec ( +- 0,01% ) 6.501.180 branch-misses # 1,66% of all branches ( +- 0,02% ) 0,304092 +- 0,000147 seconds time elapsed ( +- 0,05% ) * Importing all the standard library with PEP 657: Performance counter stats for './python import_all_stdlib.py' (500 runs): 310,56 msec task-clock # 0,999 CPUs utilized ( +- 0,06% ) 5 context-switches # 0,017 K/sec ( +- 9,39% ) 0 cpu-migrations # 0,000 K/sec 8.359 page-faults # 0,027 M/sec ( +- 0,05% ) 1.170.505.335 cycles # 3,769 GHz ( +- 0,03% ) 1.637.448.123 instructions # 1,40 insn per cycle ( +- 0,01% ) 396.921.300 branches # 1278,097 M/sec ( +- 0,01% ) 6.568.450 branch-misses # 1,65% of all branches ( +- 0,02% ) 0,310904 +- 0,000179 seconds time elapsed ( +- 0,06% ) The overhead is a 2% increase in startup time, which is 0.00681200000000004 seconds of difference. On Tue, 29 Jun 2021 at 16:39, Pablo Galindo Salgado <pablogsal@gmail.com> wrote:
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 <mark@hotpy.org> wrote:
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/
participants (3)
-
Barry Warsaw -
Mark Shannon -
Pablo Galindo Salgado