我发现自己写了太多这些:
upper = lambda c : c.upper()
lower = lambda c : c.lower()
foo = lambda a,b : a.foo(b)
如何避免或至少减少这种样板?
是不是(或者不应该)有一个PEP允许传递/调用方法作为正常程序?
答案 0 :(得分:4)
我真的没有看到你正在解决的问题。您只是从
更改方法'abc'.upper()
到
upper('abc')
它并没有真正获得任何东西,事实上它的可读性稍差。如果您正在使用lambda将key
传递给其他方法,那么您可以执行类似
l = ['ab', 'Aa', 'ca']
sorted(l, key = str.upper)
请注意,我只需拨打str.upper
即可,无需定义lambda
答案 1 :(得分:2)
如何避免或至少减少这种样板?
只是不要使用它!或者,更具体地说:
c.upper()
代替upper(c)
c.lower()
代替lower(c)
a.foo(b)
代替foo(a, b)
答案 2 :(得分:0)
您可以使用未绑定的方法,而不是创建自己的函数。
在前两个示例中,您可能需要str.upper
和str.lower
。 (如果您需要支持的时间超过str
,则可以使用operator.methodcaller("upper")
或类似内容,但请注意,处理str
和{{1}几乎肯定是一个糟糕的设计决策具有相同代码的对象!)
你的第三个例子更复杂。如果您只关心单一类型的bytes
对象,那么您可以指定它,它就像a
示例一样(例如str
)。同样,如果A.foo
的值是常量并且提前知道,则可以使用b
获取可调用operator.methodcaller("foo", b)
的可调用值,但是它为a.foo(b)
值如果a
也是可变的,那么无济于事。
如果您事先不知道b
的类型或a
,那么您确实需要坚持使用某项功能。如果你不喜欢lambda表达式的外观,你可以使用常规b
语句:
def
如果您经常使用某些内容,则可以在def foo(a, b):
return a.foo(b)
上编写自己的版本以按需生成功能:
methodcaller
然后,您使用def my_methodcaller(method_name):
def inner(obj, *args, **kwargs):
return getattr(obj, method_name)(*args, **kwargs)
return inner
。