__author__的起源是什么? [英] What is the origin of __author__?

查看:179
本文介绍了__author__的起源是什么?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在模块中使用私有元数据变量(例如__author__)的约定从何而来?

Where does the convention of using private metadata variables like __author__ within a module come from?

Python邮件列表线程似乎暗示了有关它的一些讨论2001年,但就其声音而言,这项公约已经在野外出现了.

This Python mailinglist thread seems to hint at some discussion about it in 2001, but by the sound of it the convention was already out in the wild.

除此之外,我只能在包元数据上找到此PEP ,这似乎很有影响,但最好是切线的.

Other than that, I can only find this PEP on package metadata, which seems influential but tangental at best.

我想尝试找到有关该主题的明确材料,以便我的文档工具可以成功解析这些元数据变量.

I'd like to try and find some explicit material on the subject so my documentation tool can parse these metadata variables successfully.

推荐答案

我的猜测是,这是从过去的时候打包元数据不常见的时候开始的. 在PEP 8中,鼓励使用__version__顶级变量来保存使用中的版本控制系统的修订版ID.这可以追溯到2001-05-01. PEP 396将其替换为模块__version__属性.

My guess is, it's from the old times when packaging meta data was not common then. In PEP 8 one is encouraged to use the __version__ top level variable to hold the revision id of the versioning system in use. This dates back to 2001-05-01. PEP 396 is superseding this for module __version__ attributes.

对于__author__,有一个来自python dev邮件列表的帖子,涉及此问题.这可以追溯到2001-03-01.作者质疑__author__的用法:下一步是什么?__ cute_signoff__?".

For __author__ there is a post from the python dev mailing list, concerning this matter. This one dates back to 2001-03-01. The author questions the use of __author__: "What's next ? __cute_signoff__ ?".

由于PEP中没有提及,因此我们不必担心__author__.无论如何,打包元数据是我们的朋友.

Since there is no mention in the PEPs, we don't have to worry about __author__. Packaging metadata is our friend anyway.

http://mail.python.org/pipermail/python-dev/2001-March/013328.html


Ping just checked in this:

> Log Message:
> Add __author__ and __credits__ variables.
> 
> 
> Index: tokenize.py
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Lib/tokenize.py,v
> retrieving revision 1.19
> retrieving revision 1.20
> diff -C2 -r1.19 -r1.20
> *** tokenize.py   2001/03/01 04:27:19 1.19
> --- tokenize.py   2001/03/01 13:56:40 1.20
> ***************
> *** 10,14 ****
>   it produces COMMENT tokens for comments and gives type OP for all operators."""
>   
> ! __version__ = "Ka-Ping Yee, 26 October 1997; patched, GvR 3/30/98"
>   
>   import string, re
> --- 10,15 ----
>   it produces COMMENT tokens for comments and gives type OP for all operators."""
>   
> ! __author__ = 'Ka-Ping Yee '
> ! __credits__ = 'first version, 26 October 1997; patched, GvR 3/30/98'
>   
>   import string, re

I'm slightly uncomfortable with the __credits__ variable inserted
here.  First of all, __credits__ doesn't really describe the
information given.  Second, doesn't this info belong in the CVS
history?  I'm not for including random extracts of a module's history
in the source code -- this is more likely than not to become out of
date.  (E.g. from the CVS log it's not clear why my contribution
deserves a mention while Tim's doesn't -- it looks like Tim probably
spent a lot more time thinking about it than I did.)

Anothor source of discomfort is that there's absolutely no standard
for this kind of meta-data variables.  We've got __version__, and I
believe we once agreed on that (in 1994 or so :-).  But __author__?
__credits__?  What next -- __cute_signoff__?

这篇关于__author__的起源是什么?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆