**kwargs support
BS
are you going to support **kwargs for keywords? I can't use it also in
Python code. It's being added to *args as key=value :/
Pekka Klärck
>
> are you going to support **kwargs for keywords? I can't use it also in
> Python code. It's being added to *args as key=value :/
[ Those who are not familiar with Python's keyword arguments may want
to read this to be able to follow rest of the conversation:
http://docs.python.org/tutorial/controlflow.html#keyword-arguments ]
We've discussed about having a support for kwargs but the problem is
that it's a bit hard to have a generic solution. We could simply use
"name=value" format, but what if the actual value you try to give to a
keyword actually contains just that? We could support escaping it
(e.g. "name\=value" would be considered to be just a normal string)
but the change would anyway be backwards incompatible. Another problem
is that this would not work with normal Java libraries (Java doesn't
have similar functionality), and adding support for dynamic libraries
would require more work.
Keyword arguments would be pretty handy with keywords taking many
arguments having default values. If there is for example following
keyword:
def my_kw(arg1='a', arg2='b', arg3='c', arg4='d', arg5='e'):
# do something
we could give only the last argument using syntax:
| My KW | arg5=xxx |
Currently if the last value is given, all the other values must be
given as well:
| My KW | a | b | c | d | xxx |
Keywords may have their own syntax for making this easier, but that
needs to be implemented specially for each keyword/library. Having a
built-in support in the framework would, of course, be much nicer.
Keywords shouldn't normally take too many arguments, but sometimes
that's unavoidable. We've actually faced the problem most often when
specifying initialization parameters to libraries (e.g. Telnet library
takes quite many parameters) and kwargs would resolve that problem
too.
Personally I think that kwargs are potentially so useful that the
small backwards incompatibility they would cause is acceptable.
Unfortunately implementing this wouldn't be exactly trivial, and
handling dynamic libraries and minimizing backwards incompatibilities
would make it even more complicated. This won't thus be implemented in
the near future, but submitting a feature request might be a good idea
anyway.
What about others, have you missed kwargs?
Cheers,
.peke