On Sun, Jun 27, 2010 at 4:03 PM, eric_dex...@msn.com <eric_dex...@msn.com> wrote: > On Jun 27, 2:09 pm, "Martin v. Loewis" <mar...@v.loewis.de> wrote: >> > I agree that there may be not much reason to port custom proprietary >> > apps that are working fine and which would hardly benefit from, let >> > alone need, and new Py3 features. >> >> In the long run, there will be a benefit: at some point in the future >> (surely years from now), /usr/bin/python will be Python 3. So scripts >> that use /usr/bin/python (or "/usr/bin/env python") will stop working. >> As a quick fix, it might then be possible to have them run with >> /usr/bin/python2. Some time more into the future, this will also stop >> working, as Python 2.x won't be available anymore in the OS >> distributions. If the custom proprietary app is then still used, it >> better be ported. >> >> The same happened with other kinds of deprecations and removals through >> the life of 2.x. Some applications where tied to a specific Python >> release, or to a specific feature that had been deprecated. These either >> needed to be ported, or dropped. >> >> Regards, >> Martin > > It should be easier to have a large number of python versions on one > machine... I am realy fond of 2.5 so I am probily going to start > compiling them or just include the python2.5 exe if I port stuff and > settle it that way.. > --
You're on the only platform where it isn't that easy. All us *nix users have to do is compile it with the altinstall flag, and then use #!/usr/bin/env python25 Windows uses the file extension instead of the shebang line to execute stuff, so it's harder for you to have multiple versions. -- http://mail.python.org/mailman/listinfo/python-list
