On Sat, 28 Jan 2006 23:13:12 +0100, Xavier Morel wrote: > [EMAIL PROTECTED] wrote: >> I'm a newbie experimenting with Python. I want to incrementally develop >> a module called 'circle'. The problem is now that the file name is used >> for two purposes. To keep track of the version number and as the name >> for the module. So when I develop the first version of my file I have >> to call it circle_a.py. The name of the module then automatically >> becomes circle_a. But when I develop the next increment and call my >> file circle_b.py the module name changes as well. >> >> Basically I want to decouple the version of my file from the name of >> the module. >> >> Is there a *simple* way out of this dilemma. >> > > You have two choices: > > 1- Just get rid of the version number in the name (what's the point) and > define a __version__ attribute in the module, that's what is usually done. > 2- create a wrapper module called "circle.py" whose content will be > something along the lines of "from your_current_module_with_version > import *" > > I'd strongly suggest the first choice, there is no point in giving the > version number into the file name of a module.
Modules are conceptually like a shared code library, and remember the awful problem of DLL hell on Windows? In Linux land, the convention is that libraries have the version number in the file name, so that when you install a library, it doesn't overwrite any pre-existing versions of the library. This is a Good Thing. I haven't been distributing a large number of Python applications to outsiders, so I don't know how much of a practical problem it is for Python, but if you have a rapidly changing module, with changes to the API, this is certainly a theoretical problem, if not a practical one. If it is not a problem in practice, why not? What do people do to avoid this? -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
