python类中的元数据

Jor*_*ona 4 python metadata

我在一些python库中看到了在对象中使用名为Meta的类定义的常见模式,如django Models或tastypie Resources.还有一些其他人不像Celery Tasks那样使用它.

这有什么明显的原因吗?从tastypie代码我可以看到一些元类正在使用内部的Meta类定义.元数据和模型的简单属性有什么区别吗?在django模型中有点容易说:属性只是像age = IntegerField这样的字段,但我可以在属性调用字段中思考,或者只使用_attrs或__attrs作为元数据.

这是一个好习惯吗?

再见.

编辑:

我想补充一点:

还有更多的图书馆以类似的方式接近这个吗?或者有不同的方法来做同样的事情?这里有什么常见的模式我可以检查吗?谢谢.

我想创建一个库,我喜欢这两种方式,并且与这两个库没有多大关系,因此选择其中一个库没有一致性问题

再见.

Tad*_*eck 5

不,除了惯例之外没有其他区别:TastyPie只使用Django模型用于将"数据"与"元数据"(有关数据的数据)分开的相同约定.

元类和Meta

此外,元类可以访问类属性和内部类,因此这不起任何重要作用.

为什么不_attrs__attrs

你可以命名它_attrs(可能不是__attrs由于名称修改机制),但约定是不同的(前导下划线意味着API不公开).

为什么Meta在TastyPie?

至于TastyPie和Meta内部类存储选项的原因,我建议观看Daniel Lindsley(TastyPie的创建者)的演示文稿,名为" API设计技巧 ",发布于最近的DjangoCon US 2012:http:// www.youtube.com/watch?v=IKQzXu43hzY - 它清楚地显示了使用这种特定方法构建TastyPie API的原因.

关于一致性的一点点

当谈到" 这被认为是一种好习惯吗? "部分时,我会引用PEP8的一部分("风格指南",特别是关于一致性的部分):

风格指南是关于一致性的.与此风格指南的一致性非常重要.项目的一致性更为重要.一个模块或功能内的一致性是最重要的.

因此,我将这种方法(TastyPie中的方法)视为与其开发框架(即:Django)保持一致的标志.

关于良好实践的一句话

是的,这是一个很好的做法(保持一致).使用Python样式指南(PEP8)中的命名约定也是一种很好的做法,因为它被广泛采用.但是,使用Meta内部类只是一种约定 - 如果您正在为Celery Tasks编写一些扩展,那么最好坚持使用它们的命名约定,以免混淆用户.