[Python-Dev] Rejecting PEP 473: Adding structured data to built-in exceptions
Hi, While I would like to get such new attributes, I see drawbacks as blocker issues and so I am fine with this PEP rejection. Performance is too critical for most common exceptions. For me one blocker issue is the high risk of creating reference cycles. And the weak reference API isn't the most practical :-( Moreover I expect slowdown, whereas exceptions are already expensive :-( Recently, internal code to get an attribute has been reworked to avoid exception whenever possible, and it made the code faster. Victor Le vendredi 15 mars 2019, Brett Cannon a écrit : > The steering council felt the PEP was too broad and not focused enough. Discussions about adding more attributes to built-in exceptions can continue on the issue tracker on a per-exception basis (and obviously here for any broader points, e.g. performance implications as I know that has come up before when the idea of storing relevant objects on exceptions). > Thanks to Sebastian Kreft for taking the time to write the PEP in the first place. > -- Night gathers, and now my watch begins. It shall not end until my death. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Tests for internal functionality
In https://github.com/python/cpython/pull/6541 , I was requested to add tests for an internal C function. As I wrote in https://github.com/python/cpython/pull/6541#issuecomment-445514807 , it's not clear from the codebase 1) where tests for internal (as opposed to public) functionality should be located * I only ran across very few tests for private functionality and they were located alongside the public tests. See e.g. https://github.com/python/cpython/pull/12140 -- site._getuserbase is a private function. 2) what spec one should test against since there's no official docs for internal functionality That time, they let it slide, but of course this is not something to make a habit of. It still bothers me that I left unfinished business there. Any thoughts? -- Regards, Ivan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deferring PEP 536 -- Final Grammar for Literal String Interpolation
Sorry for not having one, but my C is really not up to speed. Help is therefore very welcome of course! Am Fr., 15. März 2019 um 23:32 Uhr schrieb Brett Cannon : > The steering council decided to defer PEP 536 until an implementation is > available. > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reject PEP 472: Support for indexing with keyword arguments
Hello, I am one of the authors of the PEP. I agree with your sentiment. I still think it might be useful in some contexts and I got some positive reactions here and there, but as you said it does not seem to provide a lot of added value. On Fri, 15 Mar 2019 at 21:50, Brett Cannon wrote: > The idea never seemed to gain any traction over its near 5 years in > existence as a PEP. > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/makepython%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tests for internal functionality
On 3/16/2019 3:10 AM, Ivan Pozdeev via Python-Dev wrote: In https://github.com/python/cpython/pull/6541 , I was requested to add tests for an internal C function. As I wrote in https://github.com/python/cpython/pull/6541#issuecomment-445514807 , it's not clear from the codebase 1) where tests for internal (as opposed to public) functionality should be located In the same file where they would be if public, which is what you seemed to find. Label somehow, such as 'class InternalsTest(TestCase):' or 'test__private' (with double __ indicating test of _private). * I only ran across very few tests for private functionality and they were located alongside the public tests. See e.g. https://github.com/python/cpython/pull/12140 -- site._getuserbase is a private function. 2) what spec one should test against since there's no official docs for internal functionality Is there an informal spec in the form of docstring or comments? Besides that, test against current behavior. The main purpose of retro-testing is to detect *unintended* changes of behavior (regressions). That time, they let it slide, but of course this is not something to make a habit of. It still bothers me that I left unfinished business there. Any thoughts? -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
