that route. Explicit
> is definitely better than implicit here.
But a good idea would be to warn if __dealloc__ actually references a
Python attribute that tp_clear could have cleared, with a pointer to the
class decorator that exempts the attribute/instance from tp_clear.
Thanks and gree
know if that is easily added. I
thought it might be because Cython already has some type inference in
place!?
Greetings, Torsten
--
DYNAmore Gesellschaft fuer Ingenieurdienstleistungen mbH
Torsten Landschoff
Office Dresden
Tel: +49-(0)351-4519587
Fax: +49-(0)351-4519561
mailto:torsten.land
uot;final class DoNoExtend { ... }"
of the Java world?
In any case, Greg has a good point. I seriously did not think about it
just because I did not plan to derive from those classes.
Greetings, Torsten
--
DYNAmore Gesellschaft fuer Ingenieurdienstleistungen mbH
Torsten Landschoff
cipy, paramiko and more.
Any hint how to ensure that we are testing the local version of that
extension instead of the installed one?
Thanks, Torsten
--
DYNAmore Gesellschaft fuer Ingenieurdienstleistungen mbH
Torsten Landschoff
Office Dresden
Tel: +49-(0)351-4519587
Fax: +49-(0)351-4519561
ma
_from_gc_cycle_breaker"!?
How should the decorator to completely disable GC for a class be called?
@cython.nogc? @cython.refcounted (because the class will only support
cleanup via reference counting)?
Any input appreciated.
Greetings, Torsten
--
DYNAmore Gesellschaft fuer Ingenieurdienstlei
Hi Stefan,
On 07/14/2013 10:39 AM, Stefan Behnel wrote:
> Torsten Landschoff, 11.07.2013 00:10:
>> I attached my current (trivial) patch. Currently I only support a decorator
>>
>> @cython.noclear
>> cdef class ...
>>
>> to inhibit generation of tp_
Hi again,
On 07/14/2013 10:39 AM, Stefan Behnel wrote:
> Torsten Landschoff, 11.07.2013 00:10:
>> I attached my current (trivial) patch. Currently I only support a decorator
>>
>> @cython.noclear
>> cdef class ...
>>
>> to inhibit generation of tp_
hat you will not pull my gc_no_clear changes from
https://github.com/cython/cython/pull/248 in favor of this better fix?
Or should I update it so that gc_no_clear only has an affect on Python <
3.4?
Greetings, Torsten
--
DYNAmore Gesellschaft fuer Ingenieurdienstleistungen mbH
Torsten Landscho
