Python编程语言中有哪些鲜为人知但很有用的特性?
尽量将答案限制在Python核心。 每个回答一个特征。 给出一个例子和功能的简短描述，而不仅仅是文档链接。 使用标题作为第一行标记该特性。
快速链接到答案:
参数解包 牙套 链接比较运算符 修饰符 可变默认参数的陷阱/危险 描述符 字典默认的.get值 所以测试 省略切片语法 枚举 其他/ 函数作为iter()参数 生成器表达式 导入该 就地值交换 步进列表 __missing__物品 多行正则表达式 命名字符串格式化 嵌套的列表/生成器推导 运行时的新类型 .pth文件 ROT13编码 正则表达式调试 发送到发电机 交互式解释器中的制表符补全 三元表达式 试着/ / else除外 拆包+打印()函数 与声明
当前回答
函数参数解包
可以使用*和**将列表或字典解包为函数参数。
例如:
def draw_point(x, y):
# do some magic
point_foo = (3, 4)
point_bar = {'y': 3, 'x': 2}
draw_point(*point_foo)
draw_point(**point_bar)
非常有用的快捷方式，因为列表、元组和字典被广泛用作容器。
其他回答
Monkeypatching对象
Python中的每个对象都有__dict__成员，用于存储对象的属性。所以，你可以这样做:
class Foo(object):
def __init__(self, arg1, arg2, **kwargs):
#do stuff with arg1 and arg2
self.__dict__.update(kwargs)
f = Foo('arg1', 'arg2', bar=20, baz=10)
#now f is a Foo object with two extra attributes
可以利用这一点向对象任意添加属性和函数。这也可以用来创建一个快速和肮脏的结构类型。
class struct(object):
def __init__(**kwargs):
self.__dict__.update(kwargs)
s = struct(foo=10, bar=11, baz="i'm a string!')
很明显，反重力模块。 xkcd # 353
修饰符
装饰器允许将一个函数或方法包装在另一个函数中，该函数可以添加功能、修改参数或结果等。在函数定义的上方一行编写装饰符，以“at”符号(@)开始。
示例显示了一个print_args装饰器，它在调用被装饰函数之前打印函数的参数:
>>> def print_args(function):
>>> def wrapper(*args, **kwargs):
>>> print 'Arguments:', args, kwargs
>>> return function(*args, **kwargs)
>>> return wrapper
>>> @print_args
>>> def write(text):
>>> print text
>>> write('foo')
Arguments: ('foo',) {}
foo
消极的圆
round()函数的作用是:将浮点数四舍五入为给定精度的十进制数字，但精度可以为负数:
>>> str(round(1234.5678, -2))
'1200.0'
>>> str(round(1234.5678, 2))
'1234.57'
注意:round()总是返回一个浮点数，str()在上面的例子中使用，因为浮点数学是不精确的，并且小于2。X第二个示例可以打印为1234.5700000000001。另请参阅十进制模块。
Python的禅宗
>>> import this
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
