On Feb 20, 2006, at 1:22 PM, Ronald Oussoren wrote: > > On 20-feb-2006, at 19:51, Bob Ippolito wrote: > >> >> On Feb 20, 2006, at 9:56 AM, Ronald Oussoren wrote: >> >>> I've been thinking a little about pythonw vs. python. The former is >>> needed because on OSX any API that needs a connection to the window >>> server (anything that uses a native GUI and some other calls) >>> need to >>> be in an application bundle. pythonw is a program that can be placed >>> anywhere on the PATH and exec's a normal python interpreter >>> inside an >>> application bundle. >>> >>> As of yesterday the python24-fat tree[1] will install a copy of >>> pythonw as the normal python interpreter, that is both 'python' and >>> 'pythonw' are the same program, the one that execs an interpreter >>> inside an application bundle. This works, but at the cost of >>> additional call to exec and therefore two application startups. I >>> guess the additional cost should be lost in the noise, but the >>> micro- >>> optimizer in me isn't happy and especially so because everybody pays >>> while almost nobody should need this feature. >> >> I'd rather eat the exec call than have to listen to endless drivel >> about these little differences between Mac OS X and other >> platforms. It shouldn't take very long to do that extra exec. >> I'm frankly VERY tired of the FAQs and would like to silence as >> many as possible with our next build, even if that means a little >> performance hit or a little extra deviation from python.org >> sources. In addition to this list, I also end up with personal >> email wrt MacPython, so this is an especially large nuisance for me. > > I agree that python and pythonw should both work for GUI code, it > is something we can take care of and something new users keep > running into. This is one issue where we really could blame Apple, > but that doesn't help us very much. Annoyingly RTFM doesn't help a > lot, nobody seems to read documentation ;-(
Yeah, I've wanted this issue fixed since the beginning. They really screwed this up, and haven't done a damn thing to fix it over the past 7 years or so. Nothing we can do about that, though. >> The people that absolutely need the performance wouldn't be >> starting Python ad infinitum anyway, they'd be using daemons and/ >> or forking. If anything, higher startup cost encourages people to >> do the right thing ;) > > I don't care for higher startup costs for GUI scripts, those should > use py2app anyway. Plain boring unix scripts worry me a bit more. > But even there the startup cost should be neglectibable when > compared with the total runtime. Luckily the new pythonw is a C > program, which means the overhead is even smaller than it is in the > current MacPython release. execv should be fast, and the startup of pythonw should be totally negligible. >>> The common workaround for this is the undocumented function >>> 'CPSEnableForegroundOperation'. Another workaround might be the >>> TransformProcessType API introduced in OSX 10.3. Would it be >>> worthwhile to look into these, or is it better to worry about other >>> things instead. >> >> The other reason not to do these things is that there's a lot of >> overhead to calling CPSEnableForegroundOperation and that it >> doesn't work after some amount of time. IIRC, >> TransformProcessType doesn't work for this purpose. I believe it >> still needs argv[0] to point inside of an application bundle. It >> might be useful in "fixing" a process where it has waited too long >> before CPSEnableForegroundOperation. I don't remember exactly, >> but the details aren't very interesting either way. >> >> The pythonw-everywhere solution is a lot easier and more reliable >> than making these changes to every library that makes Carbon or >> Cocoa calls. > > If calling CPSEnableForegroundOperation or TransformProcessType at > the start of Py_Main doesn't help I'm not interested. I'm > convinced: I'm happy with the current python24-fat tree where > python and pythonw are the same program. Calling them at the start of Py_Main would likely work, but it can make the code hang for a ridiculously long time (on the order of several seconds) in my experience. Not acceptable. The execv is an acceptable hit, but this is not. -bob _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
