🌐 Mailman 3 November 2001 - Pythonmac-SIG - python.org

Python & MPW ToolServer
by Alan Lillich Nov. 15, 2001

Nov. 15, 2001

I need to port a simple testing framework and am looking at both Perl and Python. One of the things I need to do is run simple C stdio programs, passing in command line arguments and getting a numeric status back. This is obvious for UNIX (including Mac OS X) and Windows in either language. For Mac OS 9 the Perl system function lets you invoke an MPW tool or script via ToolServer, exactly what I want. Looking through the Python documentation and SIG archive, it looks like the Python fork and exec functions aren't implemented on Mac OS 9, at all let alone using ToolServer. thanks, Alan Lillich Adobe Systems Incorporated

2 1

How do I install Macpython?
by Jerry Gitomer Nov. 15, 2001

Nov. 15, 2001

I am a complete newbie when it comes to Macintosh. I have downloaded Macpython152.bin. In my ignorance I assumed that doubleclicking on the file name would start up the installation. No such luck. What do I have to do to get python installed? -- Jerry Gitomer Once I learned how to spell DBA, I became one

2 1

Re: [Pythonmac-SIG] Re: Mac OS X 10.1 build changes
by Jack Jansen Nov. 13, 2001

Nov. 13, 2001

Recently, William Noon <noon(a)snow.cit.cornell.edu> said: > Dan and Jack -- You have followed my thinking exactly. I ended up makeing > limited changes so they would have a greater chance of being accepted. I had a look at the code again, and I don't think it's worth changing. It would indeed change stuff in many more places, and your dylib/shared dichotomy does the trick. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

Re: [Pythonmac-SIG] Re: Mac OS X 10.1 build changes
by Jack Jansen Nov. 13, 2001

Nov. 13, 2001

> > I think a better solution here would be to simply set the extension for > > shared libraries to > > ".dylib" on OSX, in stead of the more common ".so". After all, they're > > really > > the same thing, and there are no .so's on OSX. > > > > What do you think? > > Well, I just did a quick search of my drive and the only .so's that I > have other than Python are > a) apache modules that came with the system and > b) those unix packages that I've installed myself (readline, bzip, > expat). > > While it's probably a great idea to use the ".dylib" extension for all > Mac OS X shared libraries, I'm not sure if I'm up to modifying all the > Unix packages that use .so's so that python or some other package looks > for for them can find them. ;-) In other words, if we modified python > to handle only dylibs then we need to modify every other package to emit > dylibs so that python can find them. And since both of them work, I'll > take the easy way out and just go for allowing both .so and .dylibs on > Mac OS X. Hmm you're right, of course. Bah, bah, bah. I wonder whether a better solution then wouldn't be to have a allow two extensions (.so and .dylib) for shared libraries, in stead of adding a new type dylib, which is really 100% the same as "shared" but only with a different extension. Should we drop this on the distutils mailing list, or is it too minor an issue to bother about? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

3 2

Stupid OS.WALK tricks?
by Schollnick, Benjamin Nov. 13, 2001

Nov. 13, 2001

Folks, I'm attempting to optimize a quick program, but os.walk is sort of interferring... I'm searching a directory tree for graphic file.... using os.walk, and when it finds the file, it copies it to a local directory... The "problem" here, is that I can't figure out how to stop OS.walk (in the visit function) from "continuing" through the rest of the directories, and to just move on to the next file... (There should only be one match).. I figure I'm going to have to write a custom walk to deal with this scenario.... Does anyone have anything similiar? Or suggestions on dealing with this? Doing a "return" or "Break" during the search doesn't seem to do this.... - Benjamin - Benjamin

3 2

Re: [Pythonmac-SIG] Re: 2.1.1 under 10.1 [was Python package maker for OS X Installer.app]
by Jack Jansen Nov. 13, 2001

Nov. 13, 2001

Hmm, I may be revising my standpoint on how to install, as superuser or as yourself. Robert and Stuart both give examples of how installing as yourself may be more dangerous in some cases (because a virus or trojan could overwrite the programs in /usr/local you know and love). The "bin" user in the "bin" group would be the best solution, but Apple doesn't have it:-( -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

Re: [Pythonmac-SIG] Re: 2.1.1 under 10.1 [was Python package maker for OS X Installer.app]
by Jack Jansen Nov. 13, 2001

Nov. 13, 2001

Recently, Robert Abernathy <rellaa(a)earthlink.net> said: > Is there a reason I wouldn't want to install the python files as owned > by root? Yes, a very good reason. The Unix adagium is (and has always been) to do as little as humanly possible as root. Taking the /usr/local/python as an example, if you do a single sudo mkdir -m 775 /usr/local then from that time on you can install anything into /usr/local using your own account (administrators are allowed to write to directories owned by group "wheel", the same group as root is in, but with no inherent extra security risks). The alternative is that you do a "sudo make install" for every package you will ever want to install in /usr/local. This means that for every package you install you have to trust the authors of the (often very complex) makefiles to not have put a trojan horse in there. Or (why blame on malevolence what you can blame on stupidity:-) not to have made stupid errors. And stupid errors happen: Apple's own iTunes 2.0 installer wiped your disk if you happened to install it on a non-system-disk with a space in the name just last weekend! -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

2 1

Re: [Pythonmac-SIG] Re: 2.1.1 under 10.1 [was Python package maker for OS X Installer.app]
by Jack Jansen Nov. 12, 2001

Nov. 12, 2001

> I can build 2.1.1 fine under 10.1 (on a UFS partition) using: > > env LDFLAGS='-flat_namespace' OPT='-no-cpp-precomp' \ > ./configure --with-dyld Ah, great! > make > make test > sudo make install Why are so many people using "sudo make install"? This is a really bad idea, I think, to install Python owned by root, but a lot of people seem to do this. Is there something in the documentation somewhere that suggests this? Another reason? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

3 2

Re: [Pythonmac-SIG] Re: Pythonmac-SIG digest, Vol 1 #894 - 7 msgs
by Jack Jansen Nov. 12, 2001

Nov. 12, 2001

> a few things... Namely most people are running HFS+, have a limited > stack space, have an old ncurses version, etc. Here's the recipe that I > use to build it... note that I muck with the makefile vs using > environmentals... which have an annoying tendency to be forgotten > several days later. The patches are for a) dylibs --> allow zlib to be > found, b) prevent ncurses from building. I have not pulled the patches > for the thread redefine from the new 2.2 CVS repository (but it doesn't > hurt anyone), nor have I fixed the fcntl case problem yet (haven't > needed it - but it apparently it needs to be made part of the core > Python vs dynamcially loaded)... :-( These patches should probably make > it into Python 2.1.2.... Please submit them to the sourceforge repository for inclusion in 2.1.2. Or, what would be even better: locate the corresponding fixes in the CVS repository and propse that these be included in 2.1.2. Andrew Kuchling is working on 2.1.2. All of the changes you're making are already in the CVS repository (or, at least, there are solutions for all the problems your patch solves), if I'm not mistaken, with one exception: your patch to recognize .dylib. I think a better solution here would be to simply set the extension for shared libraries to ".dylib" on OSX, in stead of the more common ".so". After all, they're really the same thing, and there are no .so's on OSX. What do you think? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

2 1

Re: [Pythonmac-SIG] Re: 2.1.1 under 10.1 [was Python package maker for OS X Installer.app]
by Jack Jansen Nov. 12, 2001

Nov. 12, 2001

> Hi Jack, > > My naive guess is that folks try "make install", and when that > fails (since "normal" users aren't allowed to create directories in the > default area: /usr/local/...) they decide to run the install as root so > that it will be allowed. Isn't this what most folks do on most unixish > systems anyway? Is there some security problem with this? Bingo! I knew that I knew why people did this, but I had forgotten. I'll add a note to the README that people just do the "sudo mkdir/sudo chown" and then a plain make install. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

2 1