[C++-sig] Boost.Python v2: float <==> int, anything ==> str

David Abrahams dave at boost-consulting.com
Mon Sep 2 14:39:20 CEST 2002


From: "Pearu Peterson" <pearu at cens.ioc.ee>


>
> On Sun, 1 Sep 2002, David Abrahams wrote:
>
> <snip>
>
> > So, I propose to change the built-in conversion rules for the C++
builtin
> > types as follows (note that users can explicitly add new conversions to
any
> > of these target types):
> >
> >   integer/long  require Python int or Python long (or subtype)
> >   floating      use the source type's __float__ method, if any
> >   boolean       require Python int (or subtype)
> >   string        require Python str (or subtype)
> >
> > It looks like we can actually get away with keeping the same rule for
> > floating types, though please speak up if you see some actual danger
here.
> > I'm also interested in opinions on whether Python unicode should be
> > convertible to C++ string types.
> >
> > Opinions?
>
> I am all +1 for this rule change. It will solve the problem, caused
> exactly by the current "too liberal" behaviour, that I described few
> months ago. Namely, I was trying to wrap GiNaC library that has numeric
> class representing arbitrary long integers and arbitrary precision
floats.
> Then I could not use constructors
>   numeric(int)
>   numeric(double)
> (in that order) that would convert any Python float to integer (and
> loosing information by this) or
>   numeric(double)
>   numeric(int)
> that would convert any Python int or long to float (and loosing precision
> by this). I solved it by introducing the wrapper for GiNaC::numeric so
> that
>   numeric(PyObject*)
> would take care of suitable conversation. However, this introduced many
> other problems and the interface code were becoming too big so that I
> stilled the project. After this rule change I might finalize wrapping
> GiNaC...

Fabulous, Pearu! Any chance you'd like to submit a patch for
libs/python/src/converter/builtin_converters.cpp which implements the
change?

-Dave

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com






More information about the Cplusplus-sig mailing list