boost::python, returning new PyObject references

[Barry Scott]

PyCXX does 1 for all the reasons that Guido outlined.
In PyCXX you call supportXXX functions to wire up Python object slots
up to virtual functions of the Extension class.

For example this is a fragment that creates an python extension object
that acts as supports sequence, getattr, setattr and repr.

class bemacs_buffer_data : public Py::PythonExtension<bemacs_buffer_data>
	{
// static methods
public:
	static void init_type()
		{
	        behaviors().name("bemacs_buffer");
	        behaviors().doc("bemacs buffer");
	        behaviors().supportGetattr();
	        behaviors().supportSetattr();
	        behaviors().supportRepr();
		  behaviors().supportSequenceType();
		}

I took the view that to be a sequence type requires you to wire up all the
slots that sequences typically use. I could have allowed each slot to be wire
independently, but it seems more useful to wire up all the sequence slots, or
all the mapping slots etc.

Of course you can make objects are sequences and mappings if that makes
sense in your world.

		BArry



-----Original Message-----
From: Arnaldur Gylfason [mailto:arnaldur at decode.is]
Sent: 07 January 2002 15:51
To: David Abrahams
Cc: Alex Martelli; Barry Scott; Martin Casado; Anton Gluck; Guido van
Rossum; Ullrich Koethe; Martin Casado; Niklas Blomberg; Ralf W.
Grosse-Kunstleve; scott snyder; Xavier Defrang
Subject: Re: boost::python, returning new PyObject references




> In any case, it seems as though Arnaldur and I have a choice. We can:
>
> 1. Ignore the possibility of Concepts altogether and implement a single
> generalized object interface with all capabilities.
>
> 2. Acknowledge that Concepts would be useful, but the ones that the
Python
> docs seem to imply are not really intentional. They seem to have the
right
> names, but we'd need to change them and probably carve them up a bit, and
> that would only cause confusion, so again we throw up our hands.
>
> 3. Work out a set of concept definitions that make sense, and carefully
> document them so that people are aware that "Sequence" might mean
something
> different when we say it than when the Python docs say it. Then implement
> C++ classes to represent those concepts.
>
> I'm in favor of #3, but open to others.
> Opinions, anyone?

I am in favor of #3 as well.
It has been interesting to follow the discussion between you and Guido.
I think we should work carefully on defining a set of concepts for Python
objects.
We´ll just have to accept that there can be objects that don't fit (e.g.
not defining >= 1 of the sequence methods).
Users of such objects would have to be aware of that. (They could use them
as a sequence but be aware that if a
function/method needs a sequence method the object does not define an
error/exception would occur).

In view of the discussion I've been wondering about inheritance (e.g. list
inheriting from sequence).
How about defining a python::SequenceConcept and use template parameters:
Instead of
     namespace python = boost::python;

     void f( python::sequence & s)
     {
          ...
     }

     ...

     python::sequence s(obj);
     python::list l;

     ...

     f(s);
     f(l);

we could have

     namespace python = boost::python;

     template<class SequenceType>
     void f(SequenceType & s)
     {
          boost::function_requires< python::SequenceConcept<SequenceType> >
();
          ...
     }

     ...

     python::sequence s(obj);
     python::list l;

     ...

     f(s);
     f(l);



Any opinions?


Cheers

Arnaldur