Re: [C++-sig] Sorry for my absence
Nick Rasmussen <nick@ilm.com> writes:
In case you missed this thread:
http://thread.gmane.org/gmane.comp.python.c++/7596
Do you have any opinion on this patch:
Do all the Boost.Python tests pass? Are you certain it's okay to use PyCFunction_Type as a base class even though PyFunctionObject isn't layout-compatible with boost::python::objects::function? If you can answer yes to both of those questions, and explain your answer to the second one, then we can integrate your patch. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Fri, 11 Mar 2005, David Abrahams wrote:
Nick Rasmussen <nick@ilm.com> writes:
In case you missed this thread:
http://thread.gmane.org/gmane.comp.python.c++/7596
Do you have any opinion on this patch:
Do all the Boost.Python tests pass?
On linux-x86 with python 2.3 the regression tests pass.
Are you certain it's okay to use PyCFunction_Type as a base class even though PyFunctionObject isn't layout-compatible with boost::python::objects::function?
If you can answer yes to both of those questions, and explain your answer to the second one, then we can integrate your patch.
The patch isn't using PyCFunction_Type as a base class, that was my original idea, and didn't work on all platforms: http://article.gmane.org/gmane.comp.python.c%2B%2B/7600
From talking to the python-dev folks, it's unfortunately not intended to work in any currently released version of python.
Given that there wasn't any way to make the right way work, there are three options that I came up with to make this work with existing python versions: 1: have end-users modify their installed inspect.py and/or pydoc.py files 2: replace inspect.isbuiltin dynamically on module load with a version that understands boost function types. 3: fool pydoc into thinking that boost::python functions are instances of the builtin function type. This patch attempts to solve the docstring problem via #3 since it seemed the least bad solution of the above three. That said, I'm by no means a python expert, and I don't know what all the ramifications are of overloading the __class__ attribute, I did it this way based on a suggestion from python- dev and it has worked for my needs, but it is definitely a kludge. -nick
Nick Rasmussen <nick@ilm.com> writes:
On Fri, 11 Mar 2005, David Abrahams wrote:
Nick Rasmussen <nick@ilm.com> writes:
In case you missed this thread:
http://thread.gmane.org/gmane.comp.python.c++/7596
Do you have any opinion on this patch:
Do all the Boost.Python tests pass?
On linux-x86 with python 2.3 the regression tests pass.
Are you certain it's okay to use PyCFunction_Type as a base class even though PyFunctionObject isn't layout-compatible with boost::python::objects::function?
If you can answer yes to both of those questions, and explain your answer to the second one, then we can integrate your patch.
The patch isn't using PyCFunction_Type as a base class, that was my original idea, and didn't work on all platforms:
http://article.gmane.org/gmane.comp.python.c%2B%2B/7600
From talking to the python-dev folks, it's unfortunately not intended to work in any currently released version of python.
Given that there wasn't any way to make the right way work, there are three options that I came up with to make this work with existing python versions:
1: have end-users modify their installed inspect.py and/or pydoc.py files 2: replace inspect.isbuiltin dynamically on module load with a version that understands boost function types. 3: fool pydoc into thinking that boost::python functions are instances of the builtin function type.
This patch attempts to solve the docstring problem via #3 since it seemed the least bad solution of the above three. That said, I'm by no means a python expert, and I don't know what all the ramifications are of overloading the __class__ attribute, I did it this way based on a suggestion from python- dev and it has worked for my needs, but it is definitely a kludge.
I applied it after fixing a few things: 0. Brace formatting convention 1. It does something tricky without any comments to explain what's happening!! 2. reinterpret_cast is nonportable and nearly always a no-no. Thanks for the patch. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
This patch attempts to solve the docstring problem via #3 since it seemed the least bad solution of the above three. That said, I'm by no means a python expert, and I don't know what all the ramifications are of overloading the __class__ attribute, I did it this way based on a suggestion from python- dev and it has worked for my needs, but it is definitely a kludge.
I applied it after fixing a few things:
0. Brace formatting convention
1. It does something tricky without any comments to explain what's happening!!
2. reinterpret_cast is nonportable and nearly always a no-no.
Thanks for the patch.
Probably a better thing to do would be to fake the __class__ into being a dummy class derived from PyCFunction_Type, with a noticeably different name and a big ugly docstring explaining why it exists. That way anyone looking at the __class__ attribute will have a clue what's going on. If you could make that patch, I'd appreciate it. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Fri, 11 Mar 2005, David Abrahams wrote:
David Abrahams <dave@boost-consulting.com> writes:
Probably a better thing to do would be to fake the __class__ into being a dummy class derived from PyCFunction_Type, with a noticeably different name and a big ugly docstring explaining why it exists. That way anyone looking at the __class__ attribute will have a clue what's going on. If you could make that patch, I'd appreciate it.
I don't think that's possible, for the same reason we can't inherit from it for the boost function objects. Trying it out in the interpreter, I got:
import types class Foo(types.BuiltinFunctionType): ... '''subclass of BuiltinFunctionType''' ... Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: type 'builtin_function_or_method' is not an acceptable base type
-nick
On Mon, 14 Mar 2005 09:09:55 -0800 Nick Rasmussen <nick@ilm.com> wrote:
On Fri, 11 Mar 2005, David Abrahams wrote:
David Abrahams <dave@boost-consulting.com> writes:
Probably a better thing to do would be to fake the __class__ into being a dummy class derived from PyCFunction_Type, with a noticeably different name and a big ugly docstring explaining why it exists. That way anyone looking at the __class__ attribute will have a clue what's going on. If you could make that patch, I'd appreciate it.
I don't think that's possible, for the same reason we can't inherit from it for the boost function objects. Trying it out in the interpreter, I got:
import types class Foo(types.BuiltinFunctionType): ... '''subclass of BuiltinFunctionType''' ... Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: type 'builtin_function_or_method' is not an acceptable base type
Understood, thanks.
On Fri, 2005-03-11 at 18:19 -0800, Nick Rasmussen wrote:
Given that there wasn't any way to make the right way work, there are three options that I came up with to make this work with existing python versions:
1: have end-users modify their installed inspect.py and/or pydoc.py files 2: replace inspect.isbuiltin dynamically on module load with a version that understands boost function types. 3: fool pydoc into thinking that boost::python functions are instances of the builtin function type.
There is another option that I haven't had time to fully explore - make inspect.getmodule() work for a free Boost.Python.function. I think that if the code that makes Boost.Python.class objects' __module__ member work was applied to free function objects, a trivial change could be made to inspect.getmodule(). -Jonathan
On Sat, 12 Mar 2005, Jonathan Brandmeyer wrote:
On Fri, 2005-03-11 at 18:19 -0800, Nick Rasmussen wrote:
Given that there wasn't any way to make the right way work, there are three options that I came up with to make this work with existing python versions:
1: have end-users modify their installed inspect.py and/or pydoc.py files 2: replace inspect.isbuiltin dynamically on module load with a version that understands boost function types. 3: fool pydoc into thinking that boost::python functions are instances of the builtin function type.
There is another option that I haven't had time to fully explore - make inspect.getmodule() work for a free Boost.Python.function. I think that if the code that makes Boost.Python.class objects' __module__ member work was applied to free function objects, a trivial change could be made to inspect.getmodule().
I thought about that as well, but here's what I came up with, given the premise that we don't want to do #1 or #2 above: I checked the rest of the types that show up in inspect.getfile that we could possibly use to fake out the existing code: FunctionType, CodeType, FrameType, MethodType, aren't subclassable. ModuleType is, but that doesn't seem like a good candidate to subclass, since pydoc will ignore the function again. ClassType isn't subclassable, however inspect.isclass has an extra case that doesn't show up in the other is* functions: hasattr(object,'__bases__') If we add a __bases__ attribute to the function objects, inspect.isclass will think its a class, and then if we stash a pointer to the module in __module__ the lookup would work properly. Unfortunately, if inspect.isclass reports the function as a class, pydoc tries to document it as such :/ -nick
btw, no idea if this is really on topic, but i noticed a problem with pydoc/help() that made it raise an exception when generating documentation. i could reduce the problem to an enum attribute missing. with that attribute, the help procedure went quite fine. i think it might be good to natively include this attribute. see following example for module "mu": enum_<MouseButton>("MouseButton") .value("Left",MouseButtonLeft) .value("Middle",MouseButtonMiddle) .value("Right",MouseButtonRight) .attr("__module__") = "mu" // without this attribute set, help() will raise an exception ; additionally i really miss the lack of parameter information that help() gives for exported functions. i dont think keywords should be mandatory to give people a clue on the parameter types. what about generating "hint" names for parameters from the type information if no keywords are submitted? e.g. "const char*" could be turned into "stringValue", "int" into "intValue", "Mu::Sandoz::View" into "muSandozViewValue", the second one into "muSandozViewValue2" and so on. i can imagine a complete partial template support coming on for boost.python users who want to specify their own type name translations for variables. something along the lines of template<> struct parameter_hint_from_type<Mu::Sandoz::View> { const char* name() { return "muSandozView"; } }; what do you think? Nick Rasmussen wrote:
On Sat, 12 Mar 2005, Jonathan Brandmeyer wrote:
On Fri, 2005-03-11 at 18:19 -0800, Nick Rasmussen wrote:
Given that there wasn't any way to make the right way work, there are three options that I came up with to make this work with existing python versions:
1: have end-users modify their installed inspect.py and/or pydoc.py files 2: replace inspect.isbuiltin dynamically on module load with a version that understands boost function types. 3: fool pydoc into thinking that boost::python functions are instances of the builtin function type.
There is another option that I haven't had time to fully explore - make inspect.getmodule() work for a free Boost.Python.function. I think that if the code that makes Boost.Python.class objects' __module__ member work was applied to free function objects, a trivial change could be made to inspect.getmodule().
I thought about that as well, but here's what I came up with, given the premise that we don't want to do #1 or #2 above:
I checked the rest of the types that show up in inspect.getfile that we could possibly use to fake out the existing code: FunctionType, CodeType, FrameType, MethodType, aren't subclassable. ModuleType is, but that doesn't seem like a good candidate to subclass, since pydoc will ignore the function again.
ClassType isn't subclassable, however inspect.isclass has an extra case that doesn't show up in the other is* functions: hasattr(object,'__bases__') If we add a __bases__ attribute to the function objects, inspect.isclass will think its a class, and then if we stash a pointer to the module in __module__ the lookup would work properly. Unfortunately, if inspect.isclass reports the function as a class, pydoc tries to document it as such :/
-nick
_______________________________________________ C++-sig mailing list C++-sig@python.org http://mail.python.org/mailman/listinfo/c++-sig
also, there seems to be no possibility to get the original typeid(x).name() associated with a method, class or function from within python, although this would be nice in the cases where documentation is generated from reflection in python (yes i do that).
participants (5)
-
Dave Abrahams -
David Abrahams -
Jonathan Brandmeyer -
Leonard "paniq" Ritter -
Nick Rasmussen