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 tes
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 i
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.
>
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
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
