Formal arguments of synapser functions don't match documentation or python equivalents


Edited 2020-05-07: I’ve renamed this issue because while the auto-completion issue is real, it is really a side effect of the fact that synapser functions' formal arguments don’t match what’s documented for those functions, nor the arguments for the equivalent python functions.

RStudio, Emacs/ESS, and probably most other editors provide the ability to auto complete function arguments, but auto completion does not work for synapser functions in either RStudio or Emacs.

To reproduce in RStudio or Emacs (though the latter will depend on your Emacs config): type a function name and opening paren, e.g. `read.csv(` and hit tab; this should bring up a list of possible arguments to that function which the user can choose from. If you begin to type the name of an argument, both editors will offer completion options. However if you enter a synapser function like `synLogin()` the list of arguments is not available for auto completion. See the attached video for more detail.




Jordan Kiang
September 16, 2020, 5:26 PM

There's a release candidate of synapser 0.8 available from the staging RAN server (0.8.71) (that depends on an updated PythonEmbedInR build that includes the changes from

Can you try it out and validate that it satisfies this issue? e.g.

Kara Woo
September 16, 2020, 10:19 PM

thanks for making this change. It seems to work for synLogin() but not for some others. synGet() is missing arguments:

Whereas Table seems to have an extra ... argument that's not in the documentation:

Jordan Kiang
September 16, 2020, 11:06 PM

In both these cases the definition follows the formal arguments of the wrapped Python functions:



In the case of Synapse.get the get function has arguments that are documented in its docstring,but which are defined as **kwargs in the actual function definition which is maps to R’s three dots.

Until 2.1 of the Python client similarly used only **kwargs and had no formally defined arguments, but as we have refactored some of these functions we have done a better job of formally defining the arguments and now that it does these do pass through to Synapser.

I haven’t gotten to updating get’s signature yet though. So while the formal arguments in R may not be as rich as they should be in all cases, those two examples are as expected at the moment and the fix is to formally define the arguments in the corresponding Python functions which would enrich both clients.

Kara Woo
September 16, 2020, 11:33 PM

Ah I see. I was comparing the arguments to what’s in the documentation, which I guess is generated from the docstrings. It didn’t occur to me that the formal arguments on the python side wouldn’t match what’s documented. Sounds like this is a separate known issue, so I’ll close this one.

Jordan Kiang
September 16, 2020, 11:41 PM

Okay thanks. I have made a separate Jira issue to formally define Synapse.get arguments with the next Python release as that is now an even more glaring deficiency.


Jordan Kiang


Kara Woo




Kara Woo

Development Area


Release Version History


Fix versions