Berker Peksag
Why not support Iterable[FrameSummary]?
The question that needs to be answered here is "why we should support Iterable[FrameSummary]?" and you're one the one who needs to answer it instead of saying our design decisions were "absurd" and "not wise", without giving any concrete use cases for your "wider" design choice. Initial docstring for format_list() were added in 2000: https://github.com/python/cpython/commit/e7b146fb3bdca62a0d5ecc06dbf3348e5a4... Given a list of tuples as returned by extract_tb() or extract_stack(), return a list of strings ready for printing. There are no tests for iterables other than list at https://github.com/python/cpython/blob/master/Lib/test/test_traceback.py So we won't change documentation and docstrings, add more tests without seeing concrete use cases.
What’s a “manually created iterable”?
I meant an iterable that is extracted from a traceback object manually without using extract_tb() or extract_stack() functions (by using a custom function, an external dependency, or HTTP API) How people can get Iterable[FrameSummary] as an input and pass it to format_list()?
For how long will the old API be supported for backwards compatibility reasons?
I don't remember any plans to remove the support for the old API. And I'm pretty sure we won't do anything until 2.7 is out of maintenance.
Is new code encouraged to use the new API? If the new API is better, shouldn’t new code use it? If the new API isn’t better, why was it introduced?
Are you serious? No, we've introduced the new API and spent weeks designing it just to play with people. They should stick with the old one for no reason.
----------
_______________________________________
Python tracker