[C++-sig] Static and non-static functions with the same name

[Bilokon, Paul]

 Hi Nikolay,

This is what you get. Say you have

        .def("staticGarply", (string (*)(string)) &Foo::garply)

And you comment out...

        // .staticmethod("staticGarply")

In Python, I attempt the following:

        print Foo.staticGarply('yo')

And get...

        TypeError: unbound method Boost.Python.function object must be
called with Foo instance as first argument (got str instance instead)

Regards,
Paul

-----Original Message-----
From: c++-sig-bounces at python.org [mailto:c++-sig-bounces at python.org] On
Behalf Of Nikolay Mladenov
Sent: Tuesday, August 19, 2008 6:09 PM
To: c++-sig at python.org
Subject: Re: [C++-sig] Static and non-static functions with the same
name

Please remind me, what happens if you do not put
.staticmethod("garply"), and then try :
 >>> Foo().garply(0,0)
 >>> Foo.garply("")

?

 >     class_<Foo>("Foo")
 >         .def("garply", (string (*)(string)) &Foo::garply)
 >         .def("garply", (string (Foo::*)(int, int)) &Foo::garply)
 >         .staticmethod("garply")


Bilokon, Paul wrote:
> Hi,
> 
> In C++ it's possible to have the following situation:
> 
> class Foo
> {
> public:
> 
>     string garply(int x, int y)
>     {
>         return "I am the non-static Foo::garply(int, int)";
>     }
> 
>     static string garply(string z)
>     {
>         return "I am the static Foo::garly(string)";
>     }
> };
> 
> Now I want to expose both the static and non-static garply to Python, 
> and here I'm stuck:
> 
> using namespace boost::python;
> 
> BOOST_PYTHON_MODULE(overloading)
> {
>     class_<Foo>("Foo")
>         .def("garply", (string (*)(string)) &Foo::garply)
>         .def("garply", (string (Foo::*)(int, int)) &Foo::garply)
>         .staticmethod("garply")
>             // ??? Which garply is that ???
>     ;
> }
> 
> staticmethod takes a single string as its parameter, the function
name.
> But I have both static and non-static variants. How do I specify which

> of them is static? [Technically it's possible. We already 
> differentiate between overloaded functions on the Python side, so we 
> just need to check if the first argument is "self", e.g. by looking at

> its type -- hardly foolproof though, e.g. consider a
"copy-constructor"
> signature...]
> 
> Of course, one may ask why don't I give the Python functions different

> names. But what if I'm trying to replicate the C++ API as faithfully 
> as I can? I would like to avoid name changes.
> 
> What's the best thing to do?
> 
> Many thanks!
> 
> Regards,
> Paul
> 
> 
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
> - - - - - - - - -
> 
> This message is intended only for the personal and confidential use of
the designated recipient(s) named above.  If you are not the intended
recipient of this message you are hereby notified that any review,
dissemination, distribution or copying of this message is strictly
prohibited.  This communication is for information purposes only and
should not be regarded as an offer to sell or as a solicitation of an
offer to buy any financial product, an official confirmation of any
transaction, or as an official statement of Lehman Brothers.  Email
transmission cannot be guaranteed to be secure or error-free.
Therefore, we do not represent that this information is complete or
accurate and it should not be relied upon as such.  All information is
subject to change without notice.

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

This message is intended only for the personal and confidential use of the designated recipient(s) named above.  If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited.  This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers.  Email transmission cannot be guaranteed to be secure or error-free.  Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such.  All information is subject to change without notice.