> Should we consider adding a sys.revision attribute and begin the > deprecation of sys.subversion?
I wouldn't mind killing sys.subversion "right away" (i.e. in trunk and 3k - obviously it has to stay in 2.6 and 3.1, and all the older branches). I'm -1 on calling it "sys.revision", as this makes it difficult to tell what the actual versioning system was, and hence how the data should be interpreted. It will already be a problem for 2.6, when 2.6.3 will currently have a sys.subversion[2] of 'dd3ebf81af43', which will surely crash existing applications. I'm not sure what the motivation for a sys.revision is; it's probably similar to the desire of calling the machine code.python.org (instead of hg.python.org). It gives the illusion of being agnostic of the actual RCS being used. However, this is a complete illusion: anybody using it (either code.python.org, or sys.revision), *cannot* be agnostic of the specific technology. Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
