Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #4122

Re: Py_INCREF() incomprehension

Show key headers only | View raw

Am 26.04.2011 20:44, schrieb Hegedüs Ervin:

> and (maybe) final question: :)
>
> I defined many exceptions:
>
> static PyObject *cibcrypt_error_nokey;
> static PyObject *cibcrypt_error_nofile;
> static PyObject *cibcrypt_error_badpad;
> ...
>
> void handle_err(int errcode) {
>      switch(errcode) {
>          case -1:    PyErr_SetString(cibcrypt_error_nokey, "Can't find key.");
>                      break;
> ...
> }
> ...
>      cibcrypt_error_nokey = PyErr_NewException("cibcrypt.error_nokey", NULL, NULL);
> ...
>      PyModule_AddObject(o, "error", cibcrypt_error_nokey);

Then I would not use the name "error" here, but maybe "error_nokey" or 
even better "NoKeyException".

Oops: there is an inconsistency in the docu: on the one hand, it says

   There are exactly two important exceptions to this rule:
   PyTuple_SetItem() and PyList_SetItem().

stating these are the only ones who take over ownership.

But PyModule_AddObject() claims to "steal" a reference as well...


> I am right, here also no need any Py_INCREF()/Py_DECREF() action,
> based on this doc:
> http://docs.python.org/c-api/arg.html

I'm not sure: On one hand, you pass ownership of the error objects to 
the module. There - one could think - they are until the module is unloaded.

But what if someone does "del module.NoKeyException"? In this case, the 
object could have been destroyed, and you are using it -> BANG.

On the other hand, if you keep one instance internally, it is not 
possible any longer to unload the module without a memory leak...


As already stated - you might want to have a look at some other C 
modules and mimic their behaviour... (and hope they are doing it right...)


Thomas

Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Py_INCREF() incomprehension Ervin Hegedüs <airween@gmail.com> - 2011-04-26 11:48 +0200
  Re: Py_INCREF() incomprehension Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2011-04-26 14:23 +0200
  Re: Py_INCREF() incomprehension Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2011-04-26 14:21 +0200
    Re: Py_INCREF() incomprehension Hegedüs Ervin <airween@gmail.com> - 2011-04-26 16:03 +0200
      Re: Py_INCREF() incomprehension Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2011-04-26 18:08 +0200
        Re: Py_INCREF() incomprehension Hegedüs Ervin <airween@gmail.com> - 2011-04-26 19:28 +0200
          Re: Py_INCREF() incomprehension Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2011-04-26 19:45 +0200
            Re: Py_INCREF() incomprehension Hegedüs Ervin <airween@gmail.com> - 2011-04-26 20:44 +0200
              Re: Py_INCREF() incomprehension Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2011-04-27 11:58 +0200
                Re: Py_INCREF() incomprehension Hegedüs Ervin <airween@gmail.com> - 2011-05-01 22:00 +0200
                Re: Py_INCREF() incomprehension Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-05-02 10:48 +1200
                Re: Py_INCREF() incomprehension Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2011-05-02 02:59 +0200
                Re: Py_INCREF() incomprehension Hegedüs, Ervin <airween@gmail.com> - 2011-05-02 08:41 +0200
                Re: Py_INCREF() incomprehension Stefan Behnel <stefan_ml@behnel.de> - 2011-05-02 09:07 +0200

csiph-web