寻找与此相当的python。
答案 0 :(得分:10)
也许你会更好地解释你想要做什么。对直接问题的任何解决方案都是相当单一的,因为几乎可以肯定有更好的方法来做你想做的事。
编辑(根据您的评论):
事实上,还有更好的方法。
您要做的事情被称为unpacking argument lists
,可以这样做:
self.__api_call__('POST', '/api/foobar/', **mydict)
一个工作示例:
>>> def a_plus_b(a,b):
... return a+b
...
>>> mydict = {'a':3,'b':4}
>>> a_plus_b(**mydict)
7
它也适用于kwargs,正如您所料:
>>> def a_plus_b(**kwargs):
... return kwargs['a'] + kwargs['b']
...
>>> a_plus_b(**mydict)
7
答案 1 :(得分:4)
没有。你为什么需要它?
执行以下操作(请参阅注释)
def __api_call__(self, method, resource, **kwargs):
print(kwargs)
def do_call(my_dict):
self.__api_call__('POST', '/api/foobar/', **your_dict) # double asterisk!
答案 2 :(得分:2)
通常使用locals()
来实现此结果,但确切的功能取决于您。
>>> print apple
Traceback (most recent call last):
File "<stdin>", line 1, in ?
NameError: name 'apple' is not defined
>>> print banana
Traceback (most recent call last):
File "<stdin>", line 1, in ?
NameError: name 'banana' is not defined
>>> variables = {"apple" : "a rigid, juicy fruit", "banana" : "a soft, fleshy fruit"}
>>> for variable,value in variables.iteritems():
... locals()[variable] = value
...
>>> print apple
a rigid, juicy fruit
>>> print banana
a soft, fleshy fruit
修改
感谢所有孜孜不倦地评论这种方法的不良之处的人。我完全同意这是一个不好的方法,并且在实际的回复中值得提及任何偶然发现此页面的人。 (永远不要低估这一点;我在某个地方的代码片段中看到了这种技术。我可以看到为什么在这种特殊情况下它是无害的,但我知道我不能绕过鼓励糟糕的方法,因为有些情况下它不会破裂。)
答案 3 :(得分:0)
IMO至少是一个很好的理论问题:如何实施这样的结构以及应用后它的外观如何?
例如,作为一个函数,它可以实现为
import inspect
def extract_attribute(obj, names):
if type(names) == str:
names = [names]
# Get previous frame from the inspect stack.
frame = inspect.stack()[1][0]
try:
frame_locals = frame.f_locals
attributes = inspect.getmembers(
obj, lambda attr: not inspect.ismethod(attr))
for name, attribute in attributes:
if name.startswith('__') or name.endswith('__'):
continue
if name in names:
frame_locals[name] = attribute
finally:
del frame
del frame_locals
并用作
class A(object):
foo = 'bar'
a = A()
extract_attribute(a, 'foo')
assert locals()['foo'] == 'bar'
assert foo == 'bar
注意:等待pylint会在最后一行抱怨。可以找到* extract_attribute *函数与对象一起使用,类似于导入模块的功能。将其作为范围耦合的附加层(与当前导入混合使用)将增加代码的复杂性,几乎没有例外。
PS 显而易见的操作内置是做python不是设计的事情的标志。但是自我奉承的咒语,如不实用和“非pythonic”,对我来说并不是真正适当的论据。一般来说,进行实验并查看是否更加“实用”: 1.构造将丰富语言的表达能力(例如使其更具可读性和自然性),赋予新功能等。 2.施工过于丑陋,使用危险,过于灵活和不安全,性能权衡是不可接受的,等等。 通过明确示例的插图和测试是优选的替代方案。看看代码,每个人都可以自由地发表自己的观点而不分享“专业胆量”或复制粘贴宗教教条。请不要。