Re: [C++-sig] Boost.Python.function.__signatures__
Ralf, I'm using your function signatures patch, thank you very much, it is excellent and a huge timesaver for documenting exported C++ interfaces. I wonder if you've made any updates since you posted it last month. Is your patch checked into CVS somewhere? I'm looking into making two changes: 1. At the moment, parameters which are classes exported to Python are reported with their C++ names, not their Python names (i.e., if you export the class with a different name, the docstring doesn't match the name you use in Python). Glancing over the Boost.Python code, this is over my head at the moment; is this something that seems reasonable/doable to you? 2. Parameters which are built-in C++ types are reported as single-letter names (e.g., i = int, v = void, b = boolean, x = long long, j = size_t, etc.). In your example below, it shows the real C++ type names. I wonder what's different about my configuration. Any comments or suggestions are welcome. Thanks, Ult Ralf W. Grosse-Kunstleve wrote:
--- Nick Rasmussen <nick@ilm.com> wrote:
- I guess currently the docstrings are static. They'd have to become dynamic. This seems to be a bigger project. I think we'd need a volunteer.
I'm not sure what you mean by dynamic,
It turns out my guess was wrong. Sorry.
I looked some more and here is the result:
http://cci.lbl.gov/~rwgk/boost_python/doc_signatures/function.hpp_2005_07_20...
http://cci.lbl.gov/~rwgk/boost_python/doc_signatures/function.hpp_2005_07_20...
http://cci.lbl.gov/~rwgk/boost_python/doc_signatures/function.cpp_2005_07_20...
http://cci.lbl.gov/~rwgk/boost_python/doc_signatures/function.cpp_2005_07_20...
Summary:
- I've removed my __signatures__ method.
- I've patched the getter for __doc__ to *always* append
the list of
signatures. E.g.:
help(rational.lcm)
Help on built-in function lcm:
lcm(...) C++ signature: lcm(int, int) -> int
help(rational.int().numerator)
Help on method numerator:
numerator(...) method of boost_rational_ext.int instance C++ signature: numerator(boost::rational<int> {lvalue}) -> int
This looks like *the* solution to me. Thanks a lot for your brilliant idea, Nick!
Personally I don't think we need the facilities to disable appending the signatures. Are there other opinions?
Dave, could you please briefly review my patch? It is still very simple: forward class list in function.hpp + list signatures(bool show_return_type=false) const; declaration; in function.cpp I've move some code from the body of argument_error() to the new signatures() function and I've patched the body of function_get_doc() to append the result of signatures().
Cheers, Ralf
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ C++-sig mailing list C++-sig@python.org http://mail.python.org/mailman/listinfo/c++-sig
Ult Mundane <ult@mundane.org> writes:
2. Parameters which are built-in C++ types are reported as single-letter names (e.g., i = int, v = void, b = boolean, x = long long, j = size_t, etc.). In your example below, it shows the real C++ type names. I wonder what's different about my configuration.
Looks like either Ralf isn't using __cxa_demangle (see libs/python/src/converter/type_id.cpp) or your version of GCC is < 3.1. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Thanks Dave, I was just looking at this. I'm using GCC 3.3.5, and it is going through __cxa_demangle using type_id.cpp, but __cxa_demangle returns -2, which means that it's not a mangled name to begin with. Googling offers a lot of confusion about what the correct behavior is for demangling builtin types. According to this post a while back on this list, it works in gcc 3.3 but not in gcc 3.4: http://mail.python.org/pipermail/c++-sig/2004-May/007391.html To fix it, inside gcc_demangle, I added a switch statement to translate single-character types if __cxa_demangle fails. This solves the problem. Code snippet attached for anybody who's interested. It goes in type_id.cpp inside the gcc_demangle function. It's based on the information provided here: http://www.codesourcery.com/cxx-abi/abi.html Ult David Abrahams wrote:
Ult Mundane <ult@mundane.org> writes:
2. Parameters which are built-in C++ types are reported as single-letter names (e.g., i = int, v = void, b = boolean, x = long long, j = size_t, etc.). In your example below, it shows the real C++ type names. I wonder what's different about my configuration.
Looks like either Ralf isn't using __cxa_demangle (see libs/python/src/converter/type_id.cpp) or your version of GCC is < 3.1.
if (status == -1) { throw std::bad_alloc(); } else { char const* demangled = status == -2 // Invalid mangled name. Best we can do is to // return it intact. ? mangled : keeper.p; // 2005.08.17 ult // The __cxa_demangle function is supposed to translate // builtin types from their one-character mangled names, // but it doesn't in gcc 3.3.5. #define DIRTY_NO_GOOD_DEMANGLER 1 #if DIRTY_NO_GOOD_DEMANGLER if (status == -2 && strlen(mangled) == 1) { // list from // http://www.codesourcery.com/cxx-abi/abi.html switch (mangled[0]) { case 'v': demangled = "void"; break; case 'w': demangled = "wchar_t"; break; case 'b': demangled = "bool"; break; case 'c': demangled = "char"; break; case 'a': demangled = "signed char"; break; case 'h': demangled = "unsigned char"; break; case 's': demangled = "short"; break; case 't': demangled = "unsigned short"; break; case 'i': demangled = "int"; break; case 'j': demangled = "unsigned int"; break; case 'l': demangled = "long"; break; case 'm': demangled = "unsigned long"; break; case 'x': demangled = "long long"; break; case 'y': demangled = "unsigned long long"; break; case 'n': demangled = "__int128"; break; case 'o': demangled = "unsigned __int128"; break; case 'f': demangled = "float"; break; case 'd': demangled = "double"; break; case 'e': demangled = "long double"; break; case 'g': demangled = "__float128"; break; case 'z': demangled = "..."; break; } } #endif // DIRTY_NO_GOOD_DEMANGLER p = demangler.insert(p, std::make_pair(mangled, demangled)); keeper.p = 0; }
// The __cxa_demangle function is supposed to translate // builtin types from their one-character mangled names, // but it doesn't in gcc 3.3.5.
Oh, I am surprised. I thought only 3.4 has the problem. I'd love to see Ult's patch in the CVS, with proper #ifdef's for gcc 3.4 (all versions, to my knowledge) and whatever other gcc's are affected. I've been annoyed by the gcc bug for quite some time. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Ult Mundane <ult@mundane.org> writes:
#define DIRTY_NO_GOOD_DEMANGLER 1
That's hilarious! Do you give us permission to use the code in Boost.Python under the Boost Software License version 1.0? -- Dave Abrahams Boost Consulting www.boost-consulting.com
:-) Yes of course. Ult David Abrahams wrote:
Ult Mundane <ult@mundane.org> writes:
#define DIRTY_NO_GOOD_DEMANGLER 1
That's hilarious! Do you give us permission to use the code in Boost.Python under the Boost Software License version 1.0?
--- David Abrahams <dave@boost-consulting.com> wrote:
Ult Mundane <ult@mundane.org> writes:
2. Parameters which are built-in C++ types are reported as single-letter names (e.g., i = int, v = void, b = boolean, x = long long, j = size_t, etc.). In your example below, it shows the real C++ type names. I wonder what's different about my configuration.
Looks like either Ralf isn't using __cxa_demangle (see libs/python/src/converter/type_id.cpp)
I do use the demangler all the time.
or your version of GCC is < 3.1.
gcc 3.4 has a bug. 3.3 was fine, I think 4.0 is fine too (not sure, no time to double-check because I am out of town). Cheers, Ralf __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
--- Ult Mundane <ult@mundane.org> wrote:
Ralf,
I'm using your function signatures patch, thank you very much, it is excellent and a huge timesaver for documenting exported C++ interfaces.
I wonder if you've made any updates since you posted it last month. Is your patch checked into CVS somewhere?
No, sorry, several things: - I was waiting for the boost release (done now, but...) - I am on the road now for three weeks (and this silly wireless keeps knocking me off the network...) - Nikolay Mladenov was working on a more sophisticated version: Nikolay, are you still working on this? Do you have an ETA?
I'm looking into making two changes:
1. At the moment, parameters which are classes exported to Python are reported with their C++ names, not their Python names (i.e., if you export the class with a different name, the docstring doesn't match the name you use in Python). Glancing over the Boost.Python code, this is over my head at the moment; is this something that seems reasonable/doable to you?
This was on Nikolay's list, I believe. I am not sure though I like it. One the one hand the signatures with the full C++ types tend to be long, on the other hand they are precise. I don't know how to best resolve this. ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
participants (3)
-
David Abrahams -
Ralf W. Grosse-Kunstleve -
Ult Mundane