Hi Armin,
On 04.09.2015 02:29, Armin Rigo wrote:
Hi Valentine,
On Thu, Sep 3, 2015 at 9:15 PM, Valentine Sinitsyn
wrote:
That does not make it ok to have del called several time, does it?
That's a tricky question.
If the Python documentation now says something like ``the __del__
method is
Hi Valentine,
On Thu, Sep 3, 2015 at 9:15 PM, Valentine Sinitsyn
wrote:
>> That does not make it ok to have del called several time, does it?
>
> That's a tricky question.
If the Python documentation now says something like ``the __del__
method is never called more than once on the same instance
Hi Maciej,
On 04.09.2015 00:08, Maciej Fijalkowski wrote:
On Thu, Sep 3, 2015 at 9:23 AM, Valentine Sinitsyn
wrote:
Hi Armin,
On 25.08.2015 13:00, Armin Rigo wrote:
Hi Valentine,
On 25 August 2015 at 09:56, Valentine Sinitsyn
wrote:
Yes, I think so. There is a *highly obscure* corner c
On Thu, Sep 3, 2015 at 9:23 AM, Valentine Sinitsyn
wrote:
> Hi Armin,
>
> On 25.08.2015 13:00, Armin Rigo wrote:
>>
>> Hi Valentine,
>>
>> On 25 August 2015 at 09:56, Valentine Sinitsyn
>> wrote:
Yes, I think so. There is a *highly obscure* corner case: __del__
will still be calle
Hi Armin,
On 25.08.2015 13:00, Armin Rigo wrote:
Hi Valentine,
On 25 August 2015 at 09:56, Valentine Sinitsyn
wrote:
Yes, I think so. There is a *highly obscure* corner case: __del__
will still be called several times if you declare your class with
"__slots__=()".
Even on "post-PEP-0442" P
Hi Armin,
On 25.08.2015 13:00, Armin Rigo wrote:
Hi Valentine,
On 25 August 2015 at 09:56, Valentine Sinitsyn
wrote:
Yes, I think so. There is a *highly obscure* corner case: __del__
will still be called several times if you declare your class with
"__slots__=()".
Even on "post-PEP-0442" P
Hi Armin,
On 25.08.2015 12:51, Armin Rigo wrote:
Hi Valentine,
On 24 August 2015 at 20:43, Valentine Sinitsyn
wrote:
So you mean that this was to keep things backwards compatible for
third-party extensions? I haven't thought about it this way, but this makes
sense. However, the behavior of Py
Hi Valentine,
On 25 August 2015 at 09:56, Valentine Sinitsyn
wrote:
>> Yes, I think so. There is a *highly obscure* corner case: __del__
>> will still be called several times if you declare your class with
>> "__slots__=()".
>
> Even on "post-PEP-0442" Python 3.4+? Could you share a link please?
Hi Valentine,
On 24 August 2015 at 20:43, Valentine Sinitsyn
wrote:
> So you mean that this was to keep things backwards compatible for
> third-party extensions? I haven't thought about it this way, but this makes
> sense. However, the behavior of Python code using objects with __del__ has
> chan
Hi Armin,
Thanks for replying.
On 23.08.2015 17:14, Armin Rigo wrote:
Hi Valentine,
On 19 August 2015 at 09:53, Valentine Sinitsyn
wrote:
why it wasn't possible to
implement proposed CI disposal scheme on top of tp_del?
I'm replying here as best as I understand the situation, which might
b
Hi Valentine,
On 19 August 2015 at 09:53, Valentine Sinitsyn
wrote:
> why it wasn't possible to
> implement proposed CI disposal scheme on top of tp_del?
I'm replying here as best as I understand the situation, which might
be incomplete or wrong.
From the point of view of someone writing a C ex
Hi everybody,
I'm trying to get sense of PEP-0442 [1]. Most of the looks clear,
however I wasn't able to answer myself one simple question: why it
wasn't possible to implement proposed CI disposal scheme on top of
tp_del? Common sense suggests that tp_del and tp_finalize have different
semant
12 matches
Mail list logo
