[Pythonmac-SIG] MacPython 2.1a3 also available for classic PPC

[Jack Jansen]

Recently, Russell E Owen <owen@astro.washington.edu> said:
> >Yes, it's a bit of a nuisance. PythonInterpreter is a copy of either
> >of the other two (ConfigurePythonXXX does the copying).
> >
> >I could probably try hiding the the other two, by giving them a
> >different extension and putting them in a different place, although
> >I'm not quite sure about what would be a good place. Any ideas?
> 
> Here's one idea: make PythonInterpreter an alias instead of a copy; 
> that makes it clearer what's going on, as one can resolve the alias 
> to find out which interpreter is being used. Then you could put both 
> of the specific interpreters elsewhere (e.g. in the Mac folder) or 
> just leave them where they are.

This wouldn't be good enough for the Finder. The problem is that I
want that double-clicking a Python source file will fire up the
"current" interpreter. With the current scheme this works, as long as
you-the-user don't start one of the specific interpreters before
starting the general interpreter. Still, I think this isn't good
enough, I may have to change the filetype of the specific
interpreters. Or, better, find out how to create a fat-classic-carbon
application. It's doable, things like VISE installers are created that 
way, and there's a shareware app that creates them for you. But I
would like to find out the exact scheme to use, so the
ConfigurePythonXXX scripts can make either Carbon or Classic
preferred. Any ideas are welcome.

> I tested Tk in the classic environment and it seems to mostly work. 
> The two problems I found were:
> - I cannot quit a Tk application -- after cmd-Q the output window 
> comes to the front and shows <<terminated>>, as usual, but at that 
> point I'm stuck until I do a force exit. I don't see this behavior in 
> MacPython 2.0, and I have verified that both interpreters are using 
> the same startup options.

This is a general problem: the revert-menubar-code is broken. I'll put 
it in the release notes.

> - File events are broken, as in MacPython 2.0.

> Do you have any idea what is involved in getting Tkinter to run under 
> Carbon? I am willing to do some work on it.

For MacOSX I think it's out of the question until the Tk folks port
their code. For MacOS8/9-Carbon it may be doable: there is nothing
against a Carbon app dynamically loading a shared library that is
InterfaceLib-based. So what would be needed is to create a
Python-specific Tcl/Tk shared library, InterfaceLib based, which is
loaded by _tkinter.carbon.slb.

I think the shortcut, linking _tkinter.carbon.slb as a whole against
InterfaceLib, isn't going to work because of its dependency on
PythonCoreCarbon. But maybe I'm wrong here and this would work too
(and it would definitely be a lot simpler). Maybe the link order (put
InterfaceLib before PythonCore) would do the trick?

I think we need a Python-specific tcl/tcl shared lib, because we
override a couple of tcl/tk things. But again, I'm not sure.

> Meanwhile, yes it would be great if we had a better error message. 

Ok, I'l try to do something about it.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack    | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm