469,304 Members | 2,303 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,304 developers. It's quick & easy.

__author__

I see this set (or similar) of variables in various modules I read.
They are found near the top of each module file, outside of any class
or function definitions.

"
__author__ = "Software Authors Name"
__copyright__ = "Copyright (C) 2004 Author Name"
__license__ = "Public Domain"
__version__ = "1.0"
"

What is the function of this set of variables? I assume there are
software products that use these, (Python itself, perhaps), that
expect to find certain variables explained.

What are the expected variables, other than the ones listed above, and
what software would I expect to use them?

David
Jul 18 '05 #1
12 15461
David Keeney wrote:
I see this set (or similar) of variables in various modules I read.
They are found near the top of each module file, outside of any class
or function definitions.

"
__author__ = "Software Authors Name"
__copyright__ = "Copyright (C) 2004 Author Name"
__license__ = "Public Domain"
__version__ = "1.0"
"

What is the function of this set of variables? I assume there are
software products that use these, (Python itself, perhaps), that
expect to find certain variables explained.

What are the expected variables, other than the ones listed above, and
what software would I expect to use them?


IME, other than __version__, none of these are *widely* used,
nor are they necessary.

In any case, they are all just conventions, and there are NO
"expected variables" along the lines of what you're thinking,
and while there is probably some software that uses some
particular set of them, looking for such a thing just so
that you can throw a bunch of things like that at the top
of your modules, where they will never actually be used
(except for __version__), is a waste of time, IMHO.

*If* you want to write them that way, then use them in, say,
an About Dialog or when a "-h" option is specified, then go
ahead. I personally use things like APP_AUTHOR and APP_COPYRIGHT
rather than the double-underscore convention, which in my
view makes them look like they are somehow "special" to
Python, causing just the sort of confusion that you have
faced here. :-(

-Peter
Jul 18 '05 #2
Peter L Hansen wrote:

<snip>
they will never actually be used
(except for __version__)

<snip>

So what uses __version__ ?

Thanks,
Jeffrey
Jul 18 '05 #3
David Keeney wrote:
I see this set (or similar) of variables in various modules I read.
They are found near the top of each module file, outside of any class
or function definitions.

"
__author__ = "Software Authors Name"
__copyright__ = "Copyright (C) 2004 Author Name"
__license__ = "Public Domain"
__version__ = "1.0"
"

What is the function of this set of variables? I assume there are
software products that use these, (Python itself, perhaps), that
expect to find certain variables explained.

What are the expected variables, other than the ones listed above, and
what software would I expect to use them?

David

You may be seeing those in modules that were packaged up with distutils.
The setup.py expects certain metadata about the distribution,including
those you've listed above. A list of the expected values is available on
page 562 of _Python in a Nutshell_, or in _Distributing Python Modules_
section 3, accessible at thttp://docs.python.org/dist/dist.html

HTH,
Anna

Jul 18 '05 #4
Anna Martelli Ravenscroft wrote:
You may be seeing those in modules that were packaged up with distutils.
The setup.py expects certain metadata about the distribution,including
those you've listed above. A list of the expected values is available on
page 562 of _Python in a Nutshell_, or in _Distributing Python Modules_
section 3, accessible at thttp://docs.python.org/dist/dist.html


Anna, I'd like a clarification please. Are you suggesting that
those variables as written *with underscores* are what distutils
expects to see, or merely that the names of those variables
is similar to those required by distutils? I don't see any
mention of __whatever__ on the page you cite above.

-Peter
Jul 18 '05 #5
Peter L Hansen wrote:
Anna Martelli Ravenscroft wrote:
You may be seeing those in modules that were packaged up with
distutils. The setup.py expects certain metadata about the
distribution,including those you've listed above. A list of the
expected values is available on page 562 of _Python in a Nutshell_, or
in _Distributing Python Modules_ section 3, accessible at
thttp://docs.python.org/dist/dist.html

Anna, I'd like a clarification please. Are you suggesting that
those variables as written *with underscores* are what distutils
expects to see, or merely that the names of those variables
is similar to those required by distutils? I don't see any
mention of __whatever__ on the page you cite above.


Yep - you're right.
__whatever__ isn't there. Copyright isn't on that page either (as Alex
helpfully pointed out to me after I posted this). (Good thing I said
"may". That's what I get for posting while fighting a cold...)

I hope that someone like someone whose modules use __something__ can
explain for both of us...

Anna
Jul 18 '05 #6
Jeffrey Froman wrote:
Peter L Hansen wrote:
they will never actually be used (except for __version__)


So what uses __version__ ?


Very many third party packages I have installed. It's
not that it is *consumed* by anything, but that it seems to
be a very widely used convention.

A quick scan shows it is present in:

- Twisted
- SOAPpy
- wxPython
- ReportLab
- libxml2
- fpconst
- metakit
- mx stuff
- matplotlib
- docutils
- Numeric
- OpenGL
- PIL
- pysco
- pyPgSQL
- py2exe

-Peter
Jul 18 '05 #7
Peter L Hansen wrote:
So what uses __version__ ?


Very many third party packages I have installed. It's
not that it is *consumed* by anything, but that it seems to
be a very widely used convention.


Probably because Guido suggests it in the Python Style Guide, PEP 8:

http://www.python.org/peps/pep-0008.html
--
Michael Hoffman
Jul 18 '05 #8
Peter L Hansen wrote:
Jeffrey Froman wrote:
Peter L Hansen wrote:
they will never actually be used (except for __version__)

So what uses __version__ ?

Very many third party packages I have installed. It's
not that it is *consumed* by anything, but that it seems to
be a very widely used convention.

A quick scan shows it is present in:


....
- Numeric
- OpenGL


And the plan is that newer versions of PyOpenGL are going to be using
Numeric's __version__ to decide what stub-dlls to load (or at least, to
complain if the version doesn't match what PyOpenGL was compiled
against). Generally speaking, the purpose of the meta-data is to have a
run-time queryable mechanism to determine information about the
package. Author isn't likely to be that interesting at run-time (save
for very specialised email-a-bug-report type stuff), but version allows
you to imply capabilities for the package.

Oh, IIRC, pydoc treats those __names__ as special and creates a separate
section for them (then they are duplicated in the "data" section IIRC).

Have fun,
Mike

________________________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://www.vrplumber.com
http://blog.vrplumber.com

Jul 18 '05 #9
Michael Hoffman wrote:
Peter L Hansen wrote:

[re __version__]
Very many third party packages I have installed. It's
not that it is *consumed* by anything, but that it seems to
be a very widely used convention.


Probably because Guido suggests it in the Python Style Guide, PEP 8:

http://www.python.org/peps/pep-0008.html


Checking that page.... it appears the suggestion was more specific
than that:

"""If you have to have RCS or CVS crud in your source file, do it as
follows.

__version__ = "$Revision: 1.25 $"
# $Source: /cvsroot/python/python/nondist/peps/pep-0008.txt,v $
"""

Perhaps those who have used it for a more typical version number,
ala __version__ = '1.2.34', have expanded the usage beyond what
Guido recommended.

I suspect a majority of modules actually use VERSION in preference
to __version__, maybe because many authors didn't interpret the
PEP8 comment as widely as some did.

(I've tended to use VERSION, I believe, but I'm moving towards
using a build.xml file containing a variety of meta-information
for the entire package, rather than an embedded constant.)

-Peter
Jul 18 '05 #10
Peter L Hansen wrote:
....
I suspect a majority of modules actually use VERSION in preference
to __version__, maybe because many authors didn't interpret the
PEP8 comment as widely as some did.
I'd actually be suspicious of that suspicion, I can't recall every
seeing VERSION used, while __version__ is something I've seen time and
time again. Those times I've wanted to check an installed package's
version I've always used

import package
package.__version__

in the interpreter. Never even occurred to me to use VERSION (and it's
never shown up in a dir() of a package when I've wanted to do this (that
I can recall)).
(I've tended to use VERSION, I believe, but I'm moving towards
using a build.xml file containing a variety of meta-information
for the entire package, rather than an embedded constant.)


Ah yes, much easier to work with ;) :

import package
if [int(i) for i in package.__version__.split('.')[:2]] > [2,3]:
blah()

versus:

import package
tag = findVersionTag(parseXMLFile(findXMLFile( package )))
if (findMajorVersion(tag),findMinorVersion(tag)) > (2,3):
blah()

Just teasing, you know I believe that XML is the solution to all
problems in the universe which can't be addressed *directly* with Java
;) . As long as you're exposing APIs that mean client libraries never
have to do the actual finding and parsing of the XML file, having your
"get version" API integrated into your package-management code can be
very useful for keeping them in sync.

Still, __version__ is a pretty simple API...

Smile!
Mike

________________________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://www.vrplumber.com
http://blog.vrplumber.com

Jul 18 '05 #11
Mike C. Fletcher wrote:
Peter L Hansen wrote:
(I've tended to use VERSION, I believe, but I'm moving towards
using a build.xml file containing a variety of meta-information
for the entire package, rather than an embedded constant.)


Ah yes, much easier to work with ;) :

import package
if [int(i) for i in package.__version__.split('.')[:2]] > [2,3]:
blah()

versus:

import package
tag = findVersionTag(parseXMLFile(findXMLFile( package )))
if (findMajorVersion(tag),findMinorVersion(tag)) > (2,3):
blah()

Just teasing, you know I believe that XML is the solution to all
problems in the universe which can't be addressed *directly* with Java
;) . As long as you're exposing APIs that mean client libraries never
have to do the actual finding and parsing of the XML file, having your
"get version" API integrated into your package-management code can be
very useful for keeping them in sync.

Still, __version__ is a pretty simple API...


Actually, the XML is invisible to anything outside the application,
while simplifying a variety of things relating to the rest of my
infrastructure, including automatic documentation generation,
testing framework, packaging, and revision control.

At the top of the app/package, I have a "from buildutils import build"
call, and then I can do "build.version", or "build.exename", or
whatever... if I care to support folks like you who might want to
do "xxx.__version__" I guess I should do a "__version__ = build.version"
at the top of the module... hadn't thought of that.

Basically, the stuff is read at run-time, so _you_ wouldn't
be able to tell the difference, but I have the information
maintained externally instead of being coupled to the Python
code and inaccessible to, say, InnoSetup or py2exe or my own
utilities which might not or have the means to import the
module.

And as you surmised, this is largely about keeping things in
sync and avoiding duplication. In the most recent thing that
uses this, I need pieces of the build.xml content in all the
places mentioned above, meaning I've finally achieved my goal
of removing about five different instances of duplication and
my release process can be completely automated, provided I've
remembered to update the version number at all...

-Peter
Jul 18 '05 #12
* Anna Martelli Ravenscroft (2004-10-01 18:58 +0200)
Peter L Hansen wrote:
Anna Martelli Ravenscroft wrote:

Yep - you're right.
__whatever__ isn't there. Copyright isn't on that page either (as Alex
helpfully pointed out to me after I posted this). (Good thing I said
"may". That's what I get for posting while fighting a cold...)

I hope that someone like someone whose modules use __something__ can
explain for both of us...


The standard help(module) uses at least __author__, __version__ and
__date__ to display these values separately at the bottom of the help
page so they don't get lost unnoticed in the 'data' section.

Thorsten
Jul 18 '05 #13

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by John Carter | last post: by
5 posts views Thread by Tobias Windeln | last post: by
11 posts views Thread by Amy G | last post: by
6 posts views Thread by Bart Nessux | last post: by
30 posts views Thread by Martin Bless | last post: by
4 posts views Thread by Michael Sparks | last post: by
99 posts views Thread by Paul McGuire | last post: by
10 posts views Thread by Paul Morrow | last post: by
16 posts views Thread by qwweeeit | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
reply views Thread by harlem98 | last post: by
1 post views Thread by Geralt96 | last post: by
reply views Thread by harlem98 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.