[Pythonmac-SIG] python 2.5b1
ronaldoussoren at mac.com
Thu Jun 22 20:10:43 CEST 2006
On 22-jun-2006, at 19:37, Konrad Hinsen wrote:
> On Jun 22, 2006, at 19:20, Ronald Oussoren wrote:
>> You can't please them all :-(. I'll add a warning to the readme
>> text in the installer. You can turn this feature of during
>> installation, the profile-editing step is a seperate package that
>> you can disable using the 'Customize' button. This feature was
>> discussed on this list
> OK, that's fine. I do occasionally read the readmes ;-)
This is the readme at the start of the installer, you'll have to at
least glance at it to install Python.
>> The current installers only install a number of symlinks in /usr/
>> local/bin, the real cannonical installation location is inside the
>> python framework. The reason for this is
> I noticed, and that makes sense.
>> installation of python in the default location), but more
>> importantly because distutils will by default install new scripts
>> into the bin directory inside the framework. This confuses the
>> heck out of most users that install new python packages from
>> source, even long-time Python users. By placing the framework on
>> the path thing "just work".
> That is a good argument. But if you want to change $PATH
> systemwide, why not put it in .MacOSX/environment.plist? That would
> have an effect in all shells and also in programs like Emacs that
> look for a python executable on $PATH. Moreover, it wouldn't bother
> me because my .profile redefines the path completely :-)
We don't put it in ~/MacOSX/environment.plist because that file
sucks. There's no way to update the value of PATH, you have to
provide a complete replacement. This is too bad because I'd love to
update the environment for all programs.
Another disadvantage of environment.plist is that not many people
know about it, using it would upset even more people that the ones
that don't like updates to the shell profile.
>> Now that I've defended myself it's time to move forward again ;-).
>> Why do some applications require Fink python? Is that a
>> convenience issue or does Fink's python do something that the
>> framework install cannot do? Or to phrase it differently, what should
> It's not so much the framework build as the fact that the binary
> installers have Tkinter set up for Tcl/Tk-Aqua. Fink python is set
> up for Tk/X11. Tcl-Aqua still has some bugs, and apparently also
> some more serious issues with multi-threading user interfaces.
> An example of a program that doesn't work with Tk-Aqua is PyMOL
If you multi-threading user interfaces are interfaces that update the
GUI from multiple threads I'm not surprised that this doesn't work
with the Aqua version of Tk. The native GUI model of OSX doesn't
allow this either.
Tk-Aqua also has some serious L&F issues, which is very annoying
because we're shipping IDLE as the standard python IDE and because
IDLE uses Tk it still looks bad even after some surgery to fix all
issues that I could fix (move menu's around and implement file-open-
event support). According to some Tcl/Tk sites you should use some
other Tcl library to get a good native L&F, but that isn't wrapped
yet and I definitely won't do that.
>> change to make you drop Fink or Darwinports for python stuff? And
>> I mean that *very* broadly, I'd like to make MacPython the obvious
>> choice for anyone that works with python on the mac.
> That's a good plan - I'd love to get rid of Fink if I could!
I use DarwinPorts to install unix/x11 tools. Having someone else hunt
down patches to make stuff work on darwin is much more convenient
than doing it myself. But a seperate unix installation shouldn't be
necessary to use Python.
More information about the Pythonmac-SIG