Re: Boost.Python Rich Comparisons

From: rwgk_at_[hidden]
Date: 2001-07-18 21:26:02

--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> Cool! The only thing that's the slightest bit unclear here is
> whether
> NotImplemented is supplied by boost or by the user, and if it's
> not supplied by boost, why not?

Currently it is supplied by the user (richcmp2.cpp).
It could easily be supplied by boost. That is, we could
move the current implementation of NotImplemented into
the boost::python namespace.
But then again, I am guessing that you want me to
rename the function to not_implemented, and the nice match with
the Python level NotImplemented would be lost. Also, if there
is boost::python::not_implemented, why isn't there
boost::python::none? -- A while ago we could not agree on this,
so I decided not to open this can of worms until someone asks...

> Why do you need to tell python explicitly that < <= >= and > are not
> implemented with later python versions? It seems as though the fact 
that
> you've defined == and != with this line:
> 
>     py_code.def(boost::python::operators<(  boost::python::op_eq
>                                           | boost::python::op_ne)>
());
> 
> should be enough.

Supporting this is a bit tricky.
There is only one global richcmp flag. Once any of the six
operators is defined (<, <=, ==, !=, >, >=), Python will look
for all of them. If the NotImplemented bindings
are not provided, a < b will lead to an AttributeError when
the Python 2.1 interpreter trys a.__lt__(b).
To support what you suggest, Boost.Python would have to figure
out automatically which operators are not implemented and
then provide the missing NotImplemented bindings. I am not
clear about inhomogeneous operators. To me
this seems like a fairly heavy-weight procedure for a
relatively little gain. I am tempted to put this under
"Nice features to have" at my Development Projects page.

> example1:
> 
> The DVECT_BINARY_OPERATORS macro is a little ugly. Couldn't 
something be
> done with templates and std::less<double>, std::less_equal<double>, 
etc...?

OK... where can I learn about this?

> example3:
> Whoa! I'm overwhelmed by the number of macros in this example. 
Macros aren't
> bad in and of themselves, but they're usually better avoided... for 
so many
> reasons... not the least of which is that  especially in examples 
they tend
> to obscure what's going on.

Is it possible to generate all the operators without defines
with code that compiles everywhere (i.e. without relying
on partial ordering)?
I am pretty happy with the macros in this case. There is relatively
little redundancy left. I assume that the code size would
not shrink when using templates. Again, I stuck to macros because
is am scared to run into all the usual problems caused by
broken compilers, especially Visual C++ 6.

Do you think the macros are acceptable for a start? We can always
replace them later to make it look nicer. The core library is not
affected by these changes.

Ralf