On Jun 08, 2011, at 10:47 PM, Fred Drake wrote:
On Wed, Jun 8, 2011 at 6:14 PM, Barry Warsaw
wrote: #. For modules which live inside a namespace package, the sub-package name SHOULD include the ``__version__`` attribute. The namespace module itself SHOULD NOT include its own ``__version__`` attribute.
I've no idea what you're saying here. What's a sub-package?
It's a package that lives within another package.
If you're referring to a package like zope.testing, I'd just call that a package; there's nothing special about that. I'd expect the __version__, if it exists, to be present in the file zope/testing/__init__.py.
That's where I'd expect __version__ too, and it's what the PEP tries to say. Unfortunately, I think it's ambiguous to change "sub-package" to "package" here; it just isn't clear. We're hampered by a lack of consistent terminology in the Python world about these things. I'm willing to add some definitions to the PEP to help make things clearer, or to rewrite something, but we first need to agree on what to call these things. :)
An namespace package, like zope or zc, should not have a __version__.
Agreed. Is this any clearer? #. For modules which live inside a namespace package, the module SHOULD include the ``__version__`` attribute. The namespace package itself SHOULD NOT include its own ``__version__`` attribute.
Ben Finney wrote:
I may be fighting against the tide here; but this screams to me that the PEP should not be talking at all about “version number” (except to point out that they're strings, not numbers). Instead, the term should be “version string” throughout.
I'd rather we just say 'version' instead of 'version number' or 'version string'. Natural use of natural language is... natural. A separate sentence can state simply that versions are expressed as strings.
#. The ``__version__`` attribute's value SHOULD be a string. I still don't have a problem with using "version number" to express what these things are. We have oodles of existing practice on this. -Barry