In article <rowen-81d53b.15565607042...@news.gmane.org>, "Russell E. Owen" <ro...@uw.edu> wrote: > I'm surprised you can't find it. I've always had it saved on some > obvious place. But I agree that hacking the file is ugly -- it least it > could ask.
Well, as I noted, the installer actually does warn you and give you the option to not hack it, if you follow through and click on the Customize button. Python 3 installers come with that option deselected by default, by the way, and, yes, the hack is ugly. I hope we can something a bit more elegant by the time 3.3 releases. > Other gripes about the installer: > - It names the version explicitly instead of using the Current symlink > (/Libraries/Packages/Python.Package/Versions/Current). Sorry, I don't understand that. > - It hacks the file even if doesn't need to (e.g. if Current is already > on the $PATH then the new python will be found; I think that would be > easy to check). Oh, I see. You meant with regards to how $PATH is set up. One problem with that now is that it is quite reasonable to have both a Python 2 and a Python 3 version "active" at the same time so the "Current" symlink is of less value than it once was. In fact, the Python 3 installers deliberately do not alter "Current". AFAIK, there is no other problem with having both a Python 2 bin and Python 3 bin directory on $PATH simultaneously as there is no overlap between the standard file names: all of the Python 3 bin files have a "3" included in them. (The one exception to that at the moment is "2to3" which is a bit of a special case but there are versioned names, 2to3-3.2 and 2to3-2.7, if it is necessary to distinguish them.) A case could be made I guess for using a different framework name, say Python3, so that there could be separate Current values for 2 and 3. But, I think there are bigger opportunities to rethink the installation process and layouts for Python 3.3. > - It adds a bunch of links to /usr/local/bin even though that is > redundant with putting Python's bin directory on the $PATH. This makes > it a headache to switch Python versions -- something developers often > need to do when testing compatibility. The installation of those links can also be disabled in the installer's Customize panel. But, yes, I've come around to the thinking that those links cause more trouble that they are worth, especially since the framework bin directory is where Distutils-installed script files get installed. Another potential change for 3.3. > That said, they're minor annoyances and I've not come forward to fix any > of them. And the resulting python works nicely. I guess that's the most important part :) -- Ned Deily, n...@acm.org _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
