[Pythonmac-SIG] python 2.5b1

[Ronald Oussoren]

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  
> (pymol.sourceforge.net).

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.

Ronald