|
Boost.PythonMay 2002 Progress Report |
left_operand<...>/right_operand<...>
for
asymmetric operands), I introduced a simple form of expression
templates which allow users to simply write the expressions that
should be wrapped, as in this example.
begin()
and
end()
functions:
... .def("__iter__", iterator<list_int>())
... .def("__iter__" , range(&my_class::x_begin, &my_class::x_end)) )
... .def("__iter__" , range(&std::pair<char*,char*>::first, &std::pair<char*,char*>::second)) )
... .def("__iter__", , range<return_value_policy<copy_non_const_reference> >( &my_sequence<heavy>::begin , &my_sequence<heavy>::end))
>>> f = field() >>> for e in f.elements: ... print e,This forced the exposure of the
property
interface used internally to implement the data member exposure
facility described in March. Properties are an
incredibly useful idiom, so it's good to be able to provide them
at little new development cost.
class_<>
acquired a setattr
member
function which allows users to easily add new Python objects as class
attributes.
__module__
attribute was set correctly.
back_reference
back_reference<T>
template can be used as a
function parameter when the user needs access to both a T
argument and to the Python object which manages it. The function will
only match in the overload resolution process if it would match the
same function signature with T
substituted for
back_reference<T>
. This feature is not yet
documented.
Major updates were made to the following pages:
- CallPolicies.html
- Dereferenceable.html
- Extractor.html
- HolderGenerator.html
- ResultConverter.html
- call_method.html
- callbacks.html
- data_members.html
- has_back_reference.html
- implicit.html
- instance_holder.html
- operators.html
- ptr.html
- type_id.html
- with_custodian_and_ward.html
As usual, careful documentation forces one to consider the interface again, and there were many interface changes associated with this effort, including the elevation of the following components from implementation detail to first-class library citizen:
- call.html
- updated
- class.html
- reference.html
- type_id.hpp
- pointee.hpp
- lvalue_from_pytype.hpp
char
and char const*
types, as described at
the end of April's report,
uncovered some interesting new shades to the problem. It turns out to
be worth distinguishing mutable and immutable lvalue conversions,
because despite the fact that Python doesn't understand
const
, it does understand immutability (c.f. Python
strings, which expose an immutable char
pointer). It is
also worth recognizing types which represent lvalue sequences,
to prevent Python "foobar"
from being silently
truncated to C++ 'f'
. More details on this insight can be
found in the mailing list
archive. I don't plan to do anything about this immediately, but I
do think it's the right direction to go in the long run.
http://gcc.gnu.org/ml/gcc/2002-05/msg02002.html
http://gcc.gnu.org/ml/gcc/2002-05/msg02945.html
http://gcc.gnu.org/ml/gcc/2002-05/msg01758.html
Revised 11 June, 2002
© Copyright Dave Abrahams 2002. All Rights Reserved.