Over the years, I've seen __version__ used very broadly but not *quite* in all packages. I've always known it was a convention, not a requirement. But it turns out it's not even a "official" convention.

But it really would be nice if there was a consistent way that I could count on to get the version of a package at run time.

Turns out this was suggested in PEP 396 -- and deferred almost 13 years ago!


In the status note, it says:

Further exploration of the concepts covered in this PEP has been deferred for lack of a current champion interested in promoting the goals of the PEP and collecting and incorporating feedback, and with sufficient available time to do so effectively.

Well, I may be willing to be that champion, if a core dev is willing to sponsor, and I see some interest from this group.

And, well, after 13 years, we've seen __version__ be very broadly, though certainly not universally used.

Honestly, I haven't looked to see to what extent setuptools supports it, but will, of course, do so if folks think this is worth pursuing.

Or maybe this is a settled issue in setuptools, and we just need to change the status of the PEP.

For my part, I FAR prefer the version info to be embedded in the code of the package in a simple way, rather than hiding among the setuptools/egg/pip metadata, and requiring setuptools.pkg_resources to get a version at runtime.

I note that PEP8 uses __version__ as an example of a "module level dunder" -- but only suggests where it should be put, not how it be used :-)

Of course, there will be a need to update the PEP to match current practice (and setuptools and pip)

Or should this be brought up on The Distutils-SIG list?


Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython