#922 Add doc string for virtual methods
Closed 4 years ago by tkopecek. Opened 5 years ago by till.

file modified
+27
@@ -2002,6 +2002,8 @@ 

  

  

  class VirtualMethod(object):

+     # cache for api documentation

+     _apidoc = None

      # some magic to bind an XML-RPC method to an RPC server.

      # supports "nested" methods (e.g. examples.getStateName)

      # supports named arguments (if server does)
@@ -2013,6 +2015,31 @@ 

      def __call__(self, *args, **opts):

          return self.__func(self.__name, args, opts)

  

+     @property

+     def __doc__(self):

+         # try to fetch API docs

+         if VirtualMethod._apidoc is None:

+             try:

+                 VirtualMethod._apidoc = dict(

+                     [(f["name"], f) for f in self.__func("_listapi", [], {})]

+                 )

+             except:

+                 VirtualMethod._apidoc = {}

+ 

+         funcdoc = VirtualMethod._apidoc.get(self.__name)

+         if funcdoc:

+             # add argument description to docstring since the

+             # call signature is not updated, yet

+             argdesc = funcdoc["name"] + funcdoc["argdesc"] + "\n"

+             doc = funcdoc["doc"]

+             if doc:

+                 return argdesc + doc

+             else:

+                 return argdesc

+         else:

+             return None

+ 

+ 

  

  def grab_session_options(options):

      """Convert optparse options to a dict that ClientSession can handle;

This makes the api documentation available via introspection and therefore the development of scripts easier.

Thanks! Awesome idea :smile:

The only thing that concerns me is that, while we currently only use VirtualMethod in ClientSession, there isn't really any part of it that (before this change) that explicitly ties it to that usage. Caching the _listapi result in the class var doesn't make sense if the class could be used elsewhere.

Actually.... even as is we have a problem if we have two ClientSession instances talking to two different servers with different apis.

So perhaps a slight rework of this. Maybe subclass ClientSession, add a more explicit link back to the controlling session, and cache the api data there instead.

What do you think?

So perhaps a slight rework of this. Maybe subclass ClientSession, add a more explicit link back to the controlling session, and cache the api data there instead.

err, I think I meant to subclass VirtualMethod

Metadata Update from @jcupova:
- Pull-request tagged with: testing-ready

4 years ago

Metadata Update from @jcupova:
- Pull-request tagged with: testing-done

4 years ago

Pull-Request has been closed by tkopecek

4 years ago