Message316057
| Author | eryksun |
|---|---|
| Recipients | Zuzu_Typ, amaury.forgeotdarc, belopolsky, eryksun, meador.inge |
| Date | 2018-05-02.09:16:40 |
| SpamBayes Score | -1.0 |
| Marked as misclassified | Yes |
| Message-id | <1525252600.15.0.682650639539.issue33406@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
There isn't a problem in most cases, since functions that take a callback usually call it before returning. If the library does keep a long-lived reference to a callback (e.g. a console control handler in Windows), there are ways to support this, depending on the context (e.g. global variable, class attribute, instance attribute, a dict). However, for the case where a callback should remain referenced for the lifetime of the process, it would be convenient to have a `callback_incref` option. Internally this would use a new function flag `FUNCFLAG_CALLBACK_INCREF`. |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2018-05-02 09:16:40 | eryksun | set | recipients: + eryksun, amaury.forgeotdarc, belopolsky, meador.inge, Zuzu_Typ |
| 2018-05-02 09:16:40 | eryksun | set | messageid: <1525252600.15.0.682650639539.issue33406@psf.upfronthosting.co.za> |
| 2018-05-02 09:16:40 | eryksun | link | issue33406 messages |
| 2018-05-02 09:16:40 | eryksun | create | |