On Mon, 04 Feb 2008 20:22:04 +0900 "Stephen J. Turnbull" <[EMAIL PROTECTED]> wrote: > Marcin ___Qrczak___ Kowalczyk writes: > > Dnia 03-02-2008, N o godzinie 10:24 +0900, Stephen J. Turnbull pisze: > > > I don't see any need to shorten "python3.0" to "python3". > > There is a need. Using #!/usr/bin/python3.0 would break as soon as > > python3.1 is released, while #!/usr/bin/python3 would be fine, at > > least in the next few years. > First of all, under current policy, installing Python 3.1 would not > uninstall or overwrite Python 3.0
Wrong. The recommend "make install" overwrites the "python" link. > so nothing "breaks" when the user uses #!/usr/bin/python3.0. Unless, of course, the user used their systems packaging software to upgrade the default python install, and that's been moved to the newer version. In that case, every packaging system I've ever used will remove the old version, thus breaking any scripts that were foolish enough to use that form. Which is why those packaging systems pretty much all install python scripts using "python" for the executable. > On the contrary, Python 3.1 itself may be buggy. I do not think is > it appropriate for the Python installer to make that decision for > the user by creating a link to the most recent python3.x. Except it currently does, both during the install from source *and* as installed by most packaging systems. If the packaging system does things right, this isn't really a problem - until you get to 3.0, because it breaks backwards compatibility. > What I see no need for is a policy statement *by Python* that there > "should" be a "python3" link, or which python3.x is should point to. So do you think we should do away with the "python" link as well? > I don't think that Python providing a simple tool to help the user do > it is a good idea, either, because most OS distributions already > provide them, and they tend to be rather obnoxious about "rogue" users > who do it by hand or use 3d party (including upstream) tools to do it. The reason OS distributions are hard on "rogue" users who change the meaning of "python" is because their system tools quit working when you do that, as they all use "python". So when they start shipping python3, they'll tend to make "python" invoke the old version until they convert all their scrips, as RH did with 1 and 2. Except RH still has a python2 alias, so they can easily switch their scripts to python2 if they chose to do so. Personally, I'd rather they do the latter than the former, so people will get a modern version of python when they ask for python on that OS. Most of the time, having a default for both python and python of a specific major version is pointless, because you're only going to have one major version installed, even if you have multiple minor versions installed, so they're both the same. The exception is when a new major version arrives breaking backwards compatibility. At that time, it's nice to have a default for the major versions so scripts can pick the major version if they're not picky about minor versions (and given how much work we do making sure the language is backwards compatible at that level, there are a lot of those) at the same time as users pick what they want to get when they say "python". Having the python install provide the major version link as well as the versionless "python" link means it becomes reasonable to distribute scripts that use link, because most installs will have it. It encourages vendors to use that link in their system-specific scripts, so they can provide a backwards-incompatible version of python, and make "python" invoke it for users. Both of these are good things. <mike -- Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com