Re: stuffing a PyObject into a object

> > I can understand this except for a couple of
things,
> >
> > What is the PyIter_Next there for? demonstration
purposes? or is it
 an
> > essential part of the conversion? Same question
for that whole second
> > line.
>
> I think it's a mistake.

This is five years ago, but IIRC my reply was meant as food
for thought.
Why does it have to be a two-stage procedure with the detour
through handle<>?
My understanding was: it is meant to make you think about
PyObject* = 0.

> > will 'allow_null' make a 'None' out of a null
pointer? or do some
> > other crazy thing?
>
> No, it makes a null handle.  It seems superfluous,
since the object
> ctor will throw an exception anyway if its argument is
null.

I wanted to give a realistic example why you may care about
PyObject* = 0.
We want to detect PyObject* = 0 without getting an exception
(// end of iteration)
*and* we don't want to have the bare PyObject* floating
around since we
may forget to decref later.

> > I am trying to understand what is going on, and
not just fall into
> > guess and check programming.
>
> Good call.

Guess and check is a fantastic way to find out what is going
on
(or as Germany's most famous poet, Goethe, put it: Probieren
geht
ueber studieren).

Here is an example:

  void
  foo()
  {
    using namespace boost::python;
    PyObject* obj = 0;
    handle<> h(allow_null(obj));
    std::cout << "HELLO" << std::endl
<< std::flush;
  }

If you compile and run this function it will finish fine and
show the HELLO.
Without the allow_null() I get this:

SystemError: NULL result without error in PyObject_Call

and no HELLO.

Ralf



_______________________________________________
C++-sig mailing list
C++-sigpython.org
http:
//mail.python.org/mailman/listinfo/c++-sig