RetroSearch Browse

Fri Jul 3 23:00:35 CEST 2009 · https://mail.python.org/pipermail/python-dev/2009-July/090363.html

> 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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2009-July/090363.html below:

[Python-Dev] Mercurial migration: progress report (PEP 385)