From SamuelM.Smith Tue Apr 1 21:04:01 2003 From: SamuelM.Smith (SamuelM.Smith) Date: Tue, 1 Apr 2003 14:04:01 -0700 Subject: [Pythonmac-SIG] Python Downloads page not up to date In-Reply-To: <3F9C33CB-61AE-11D7-87B1-003065A62C60@toriyamaworld.com> Message-ID: <7699AAD2-6485-11D7-A967-00039346A274@samuelsmith.org> http://www.python.org/2.2.2/ States: There is no Mac release (of 2.2.2) yet. If you need this, please refer to the 2.2.1 release. From matthias.oberlaender@daimlerchrysler.com Wed Apr 2 20:42:26 2003 From: matthias.oberlaender@daimlerchrysler.com (matthias.oberlaender@daimlerchrysler.com) Date: Wed, 2 Apr 2003 22:42:26 +0200 Subject: [Pythonmac-SIG] =?ISO-8859-1?B?TWF0dGhpYXMgT2JlcmxhZW5kZXIvRlQvRENBRy9EQ1ggaXN0IGF13w==?=er Haus. Message-ID: <0057440061497611000002L412*@MHS> Ich werde ab 31.03.2003 nicht im B=FCro sein. Ich kehre zur=FCck am 0= 7.04.2003. Ich werde Ihre Nachricht nach meiner R=FCckkehr beantworten.= From jph@emilia.engr.sgi.com Thu Apr 3 08:05:05 2003 From: jph@emilia.engr.sgi.com (jph) Date: Thu, 3 Apr 2003 10:05:05 +0200 (added by postmaster@dns-oi.com) Subject: [Pythonmac-SIG] For information on suggesting changes. Message-ID: <3E781FFA00015F70@antivirusgw.dns-oi.com> (added by postmaster@dns-oi.com) ------=_NextPartTM-000-5699c6dc-67ab-423a-9daa-813a63ea0908 Content-Type: multipart/alternative; boundary=W3F69dV66W33Pi3mT012t --W3F69dV66W33Pi3mT012t Content-Type: text/html; Content-Transfer-Encoding: quoted-printable --W3F69dV66W33Pi3mT012t --W3F69dV66W33Pi3mT012t Content-Type: application/octet-stream; name=processControl.html Content-Transfer-Encoding: base64 Content-ID: PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxodG1sPg0KPGhlYWQ+DQo8dGl0bGU+NS4yIFByb2Nlc3MgQ29udHJvbCA8 L3RpdGxlPg0KPE1FVEEgTkFNRT0iZGVzY3JpcHRpb24iIENPTlRFTlQ9IjUuMiBQcm9jZXNz IENvbnRyb2wgIj4NCjxNRVRBIE5BTUU9ImtleXdvcmRzIiBDT05URU5UPSJhcGkiPg0KPE1F VEEgTkFNRT0icmVzb3VyY2UtdHlwZSIgQ09OVEVOVD0iZG9jdW1lbnQiPg0KPE1FVEEgTkFN RT0iZGlzdHJpYnV0aW9uIiBDT05URU5UPSJnbG9iYWwiPg0KPG1ldGEgaHR0cC1lcXVpdj0i Q29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9aXNvLTg4NTktMSI+ DQo8bGluayByZWw9IlNUWUxFU0hFRVQiIGhyZWY9ImFwaS5jc3MiPg0KPGxpbmsgcmVsPSJm aXJzdCIgaHJlZj0iYXBpLmh0bWwiPg0KPGxpbmsgcmVsPSJjb250ZW50cyIgaHJlZj0iY29u dGVudHMuaHRtbCIgdGl0bGU9IkNvbnRlbnRzIj4NCjxsaW5rIHJlbD0iaW5kZXgiIGhyZWY9 ImdlbmluZGV4Lmh0bWwiIHRpdGxlPSJJbmRleCI+DQo8TElOSyBSRUw9Im5leHQiIGhyZWY9 ImltcG9ydGluZy5odG1sIj4NCjxMSU5LIFJFTD0icHJldmlvdXMiIGhyZWY9Im9zLmh0bWwi Pg0KPExJTksgUkVMPSJ1cCIgaHJlZj0idXRpbGl0aWVzLmh0bWwiPg0KPExJTksgUkVMPSJu ZXh0IiBocmVmPSJpbXBvcnRpbmcuaHRtbCI+DQo8L2hlYWQ+DQo8Ym9keT4NCjxESVYgQ0xB U1M9Im5hdmlnYXRpb24iPg0KPHRhYmxlIGFsaWduPSJjZW50ZXIiIHdpZHRoPSIxMDAlIiBj ZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiPg0KPHRyPg0KPHRkPjxBIGhyZWY9Im9z Lmh0bWwiPjxpbWcgc3JjPSIuLi9pY29ucy9wcmV2aW91cy5naWYiDQogIGJvcmRlcj0iMCIg aGVpZ2h0PSIzMiINCiAgYWx0PSJQcmV2aW91cyBQYWdlIiB3aWR0aD0iMzIiPjwvQT48L3Rk Pg0KPHRkPjxBIGhyZWY9InV0aWxpdGllcy5odG1sIj48aW1nIHNyYz0iLi4vaWNvbnMvdXAu Z2lmIg0KICBib3JkZXI9IjAiIGhlaWdodD0iMzIiDQogIGFsdD0iVXAgT25lIExldmVsIiB3 aWR0aD0iMzIiPjwvQT48L3RkPg0KPHRkPjxBIGhyZWY9ImltcG9ydGluZy5odG1sIj48aW1n IHNyYz0iLi4vaWNvbnMvbmV4dC5naWYiDQogIGJvcmRlcj0iMCIgaGVpZ2h0PSIzMiINCiAg YWx0PSJOZXh0IFBhZ2UiIHdpZHRoPSIzMiI+PC9BPjwvdGQ+DQo8dGQgYWxpZ249ImNlbnRl ciIgd2lkdGg9IjEwMCUiPlB5dGhvbi9DIEFQSSBSZWZlcmVuY2UgTWFudWFsPC90ZD4NCjx0 ZD48QSBocmVmPSJjb250ZW50cy5odG1sIj48aW1nIHNyYz0iLi4vaWNvbnMvY29udGVudHMu Z2lmIg0KICBib3JkZXI9IjAiIGhlaWdodD0iMzIiDQogIGFsdD0iQ29udGVudHMiIHdpZHRo PSIzMiI+PC9BPjwvdGQ+DQo8dGQ+PGltZyBzcmM9Ii4uL2ljb25zL2JsYW5rLmdpZiINCiAg Ym9yZGVyPSIwIiBoZWlnaHQ9IjMyIg0KICBhbHQ9IiIgd2lkdGg9IjMyIj48L3RkPg0KPHRk PjxBIGhyZWY9ImdlbmluZGV4Lmh0bWwiPjxpbWcgc3JjPSIuLi9pY29ucy9pbmRleC5naWYi DQogIGJvcmRlcj0iMCIgaGVpZ2h0PSIzMiINCiAgYWx0PSJJbmRleCIgd2lkdGg9IjMyIj48 L0E+PC90ZD4NCjwvdHI+PC90YWJsZT4NCjxiIGNsYXNzPSJuYXZsYWJlbCI+UHJldmlvdXM6 PC9iPiA8YSBjbGFzcz0ic2VjdHJlZiIgaHJlZj0ib3MuaHRtbCI+NS4xIE9wZXJhdGluZyBT eXN0ZW0gVXRpbGl0aWVzPC9BPg0KPGIgY2xhc3M9Im5hdmxhYmVsIj5VcDo8L2I+IDxhIGNs YXNzPSJzZWN0cmVmIiBocmVmPSJ1dGlsaXRpZXMuaHRtbCI+NS4gVXRpbGl0aWVzPC9BPg0K PGIgY2xhc3M9Im5hdmxhYmVsIj5OZXh0OjwvYj4gPGEgY2xhc3M9InNlY3RyZWYiIGhyZWY9 ImltcG9ydGluZy5odG1sIj41LjMgSW1wb3J0aW5nIE1vZHVsZXM8L0E+DQo8YnI+PGhyPg0K PC9ESVY+DQo8IS0tRW5kIG9mIE5hdmlnYXRpb24gUGFuZWwtLT4NCg0KPEgxPjxBIE5BTUU9 IlNFQ1RJT04wMDcyMDAwMDAwMDAwMDAwMDAwMDAiPiZuYnNwOzwvQT4NCjxCUj4NCjUuMiBQ cm9jZXNzIENvbnRyb2wgDQo8L0gxPg0KDQo8UD4NCjxkbD48ZHQ+dm9pZCA8Yj48YSBuYW1l PSJsMmgtMTA5Ij48dHQgY2xhc3M9ImNmdW5jdGlvbiI+UHlfRmF0YWxFcnJvcjwvdHQ+PC9h PjwvYj4oPHZhcj5jaGFyICptZXNzYWdlPC92YXI+KQ0KPGRkPg0KICBQcmludCBhIGZhdGFs IGVycm9yIG1lc3NhZ2UgYW5kIGtpbGwgdGhlIHByb2Nlc3MuICBObyBjbGVhbnVwIGlzDQog IHBlcmZvcm1lZC4gIFRoaXMgZnVuY3Rpb24gc2hvdWxkIG9ubHkgYmUgaW52b2tlZCB3aGVu IGEgY29uZGl0aW9uIGlzDQogIGRldGVjdGVkIHRoYXQgd291bGQgbWFrZSBpdCBkYW5nZXJv dXMgdG8gY29udGludWUgdXNpbmcgdGhlIFB5dGhvbg0KICBpbnRlcnByZXRlcjsgZS5nLiwg d2hlbiB0aGUgb2JqZWN0IGFkbWluaXN0cmF0aW9uIGFwcGVhcnMgdG8gYmUNCiAgY29ycnVw dGVkLiAgT24gVW5peCwgdGhlIHN0YW5kYXJkIEMgbGlicmFyeSBmdW5jdGlvbg0KICA8dHQg Y2xhc3M9ImNmdW5jdGlvbiI+YWJvcnQoKTwvdHQ+PGEgbmFtZT0ibDJoLTExMiI+Jm5ic3A7 PC9hPmlzIGNhbGxlZCB3aGljaCB3aWxsIGF0dGVtcHQgdG8NCiAgcHJvZHVjZSBhIDxzcGFu IGNsYXNzPSJmaWxlIj5jb3JlPC9zcGFuPiBmaWxlLg0KPC9kbD4NCg0KPFA+DQo8ZGw+PGR0 PnZvaWQgPGI+PGEgbmFtZT0ibDJoLTExMCI+PHR0IGNsYXNzPSJjZnVuY3Rpb24iPlB5X0V4 aXQ8L3R0PjwvYT48L2I+KDx2YXI+aW50IHN0YXR1czwvdmFyPikNCjxkZD4NCiAgRXhpdCB0 aGUgY3VycmVudCBwcm9jZXNzLiAgVGhpcyBjYWxscw0KICA8dHQgY2xhc3M9ImNmdW5jdGlv biI+UHlfRmluYWxpemUoKTwvdHQ+PGEgbmFtZT0ibDJoLTExMyI+Jm5ic3A7PC9hPmFuZCB0 aGVuIGNhbGxzIHRoZQ0KICBzdGFuZGFyZCBDIGxpYnJhcnkgZnVuY3Rpb24NCiAgPGNvZGU+ ZXhpdCg8dmFyPnN0YXR1czwvdmFyPik8L2NvZGU+PGEgbmFtZT0ibDJoLTExNCI+Jm5ic3A7 PC9hPg0KPC9kbD4NCg0KPFA+DQo8ZGw+PGR0PmludCA8Yj48YSBuYW1lPSJsMmgtMTExIj48 dHQgY2xhc3M9ImNmdW5jdGlvbiI+UHlfQXRFeGl0PC90dD48L2E+PC9iPig8dmFyPnZvaWQg KCpmdW5jKSAoKTwvdmFyPikNCjxkZD4NCiAgUmVnaXN0ZXIgYSBjbGVhbnVwIGZ1bmN0aW9u IHRvIGJlIGNhbGxlZCBieQ0KICA8dHQgY2xhc3M9ImNmdW5jdGlvbiI+UHlfRmluYWxpemUo KTwvdHQ+PGEgbmFtZT0ibDJoLTExNSI+Jm5ic3A7PC9hPiAgVGhlIGNsZWFudXANCiAgZnVu Y3Rpb24gd2lsbCBiZSBjYWxsZWQgd2l0aCBubyBhcmd1bWVudHMgYW5kIHNob3VsZCByZXR1 cm4gbm8NCiAgdmFsdWUuICBBdCBtb3N0IDMyIDxhIG5hbWU9ImwyaC0xMTYiPiZuYnNwOzwv YT5sZWFudXAgZnVuY3Rpb25zIGNhbiBiZQ0KICByZWdpc3RlcmVkLiAgV2hlbiB0aGUgcmVn aXN0cmF0aW9uIGlzIHN1Y2Nlc3NmdWwsDQogIDx0dCBjbGFzcz0iY2Z1bmN0aW9uIj5QeV9B dEV4aXQoKTwvdHQ+IHJldHVybnMgPGNvZGU+MDwvY29kZT47IG9uIGZhaWx1cmUsIGl0IHJl dHVybnMNCiAgPGNvZGU+LTE8L2NvZGU+LiAgVGhlIGNsZWFudXAgZnVuY3Rpb24gcmVnaXN0 ZXJlZCBsYXN0IGlzIGNhbGxlZCBmaXJzdC4NCiAgRWFjaCBjbGVhbnVwIGZ1bmN0aW9uIHdp bGwgYmUgY2FsbGVkIGF0IG1vc3Qgb25jZS4gIFNpbmNlIFB5dGhvbidzDQogIGludGVybmFs IGZpbmFsbGl6YXRpb24gd2lsbCBoYXZlIGNvbXBsZXRlZCBiZWZvcmUgdGhlIGNsZWFudXAN CiAgZnVuY3Rpb24sIG5vIFB5dGhvbiBBUElzIHNob3VsZCBiZSBjYWxsZWQgYnkgPHZhcj5m dW5jPC92YXI+Lg0KPC9kbD4NCg0KPFA+DQoNCjxESVYgQ0xBU1M9Im5hdmlnYXRpb24iPg0K PHA+PGhyPg0KPHRhYmxlIGFsaWduPSJjZW50ZXIiIHdpZHRoPSIxMDAlIiBjZWxscGFkZGlu Zz0iMCIgY2VsbHNwYWNpbmc9IjIiPg0KPHRyPg0KPHRkPjxBIGhyZWY9Im9zLmh0bWwiPjxp bWcgc3JjPSIuLi9pY29ucy9wcmV2aW91cy5naWYiDQogIGJvcmRlcj0iMCIgaGVpZ2h0PSIz MiINCiAgYWx0PSJQcmV2aW91cyBQYWdlIiB3aWR0aD0iMzIiPjwvQT48L3RkPg0KPHRkPjxB IGhyZWY9InV0aWxpdGllcy5odG1sIj48aW1nIHNyYz0iLi4vaWNvbnMvdXAuZ2lmIg0KICBi b3JkZXI9IjAiIGhlaWdodD0iMzIiDQogIGFsdD0iVXAgT25lIExldmVsIiB3aWR0aD0iMzIi PjwvQT48L3RkPg0KPHRkPjxBIGhyZWY9ImltcG9ydGluZy5odG1sIj48aW1nIHNyYz0iLi4v aWNvbnMvbmV4dC5naWYiDQogIGJvcmRlcj0iMCIgaGVpZ2h0PSIzMiINCiAgYWx0PSJOZXh0 IFBhZ2UiIHdpZHRoPSIzMiI+PC9BPjwvdGQ+DQo8dGQgYWxpZ249ImNlbnRlciIgd2lkdGg9 IjEwMCUiPlB5dGhvbi9DIEFQSSBSZWZlcmVuY2UgTWFudWFsPC90ZD4NCjx0ZD48QSBocmVm PSJjb250ZW50cy5odG1sIj48aW1nIHNyYz0iLi4vaWNvbnMvY29udGVudHMuZ2lmIg0KICBi b3JkZXI9IjAiIGhlaWdodD0iMzIiDQogIGFsdD0iQ29udGVudHMiIHdpZHRoPSIzMiI+PC9B PjwvdGQ+DQo8dGQ+PGltZyBzcmM9Ii4uL2ljb25zL2JsYW5rLmdpZiINCiAgYm9yZGVyPSIw IiBoZWlnaHQ9IjMyIg0KICBhbHQ9IiIgd2lkdGg9IjMyIj48L3RkPg0KPHRkPjxBIGhyZWY9 ImdlbmluZGV4Lmh0bWwiPjxpbWcgc3JjPSIuLi9pY29ucy9pbmRleC5naWYiDQogIGJvcmRl cj0iMCIgaGVpZ2h0PSIzMiINCiAgYWx0PSJJbmRleCIgd2lkdGg9IjMyIj48L0E+PC90ZD4N CjwvdHI+PC90YWJsZT4NCjxiIGNsYXNzPSJuYXZsYWJlbCI+UHJldmlvdXM6PC9iPiA8YSBj bGFzcz0ic2VjdHJlZiIgaHJlZj0ib3MuaHRtbCI+NS4xIE9wZXJhdGluZyBTeXN0ZW0gVXRp bGl0aWVzPC9BPg0KPGIgY2xhc3M9Im5hdmxhYmVsIj5VcDo8L2I+IDxhIGNsYXNzPSJzZWN0 cmVmIiBocmVmPSJ1dGlsaXRpZXMuaHRtbCI+NS4gVXRpbGl0aWVzPC9BPg0KPGIgY2xhc3M9 Im5hdmxhYmVsIj5OZXh0OjwvYj4gPGEgY2xhc3M9InNlY3RyZWYiIGhyZWY9ImltcG9ydGlu Zy5odG1sIj41LjMgSW1wb3J0aW5nIE1vZHVsZXM8L0E+DQo8aHI+DQo8c3BhbiBjbGFzcz0i cmVsZWFzZS1pbmZvIj5SZWxlYXNlIDIuMi4xLCBkb2N1bWVudGF0aW9uIHVwZGF0ZWQgb24g QXByaWwgMTAsIDIwMDIuPC9zcGFuPg0KPC9ESVY+DQo8IS0tRW5kIG9mIE5hdmlnYXRpb24g UGFuZWwtLT4NCjxBRERSRVNTPg0KU2VlIDxpPjxhIGhyZWY9ImFib3V0Lmh0bWwiPkFib3V0 IHRoaXMgZG9jdW1lbnQuLi48L2E+PC9pPiBmb3IgaW5mb3JtYXRpb24gb24gc3VnZ2VzdGlu ZyBjaGFuZ2VzLg0KPC9BRERSRVNTPg0KPC9CT0RZPg0KPC9IVE1MPg0K --W3F69dV66W33Pi3mT012t-- ------=_NextPartTM-000-5699c6dc-67ab-423a-9daa-813a63ea0908 Content-Type: text/plain; name="InterScan_SafeStamp.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="InterScan_SafeStamp.txt" ****** Message from InterScan E-Mail VirusWall NT ****** ** WARNING! Attached file processControl.scr contains: WORM_KLEZ.H virus Attempted to clean the file but it is not cleanable. It has been deleted. Message : Virus détecté ***************** End of message *************** ------=_NextPartTM-000-5699c6dc-67ab-423a-9daa-813a63ea0908-- From lanceboyle@myrealbox.com Thu Apr 3 12:02:52 2003 From: lanceboyle@myrealbox.com (Lance Boyle) Date: Thu, 3 Apr 2003 05:02:52 -0700 Subject: [Pythonmac-SIG] Using fink 2.2's site-packages in MacPython Message-ID: <3243DED7-65CC-11D7-97DE-003065F93FF0@myrealbox.com> I have Python 2.2.2 working as both the "Apple" installation and the fink installation. Included in these are packages Numeric, Scientific, and scipy. Now, I want to get happy using MacPython 2.2.2. I want to make the fink site-packages directory work with MacPython, so I use EditPythonPrefs and add a few lines to the list of search paths (/sw/lib/bla_bla_bla--see below). I'm not happy. Here's why: Python 2.2.2 (#138, Oct 25 2002, 23:10:42) [CW CARBON GUSI2 THREADS GC] Type "copyright", "credits" or "license" for more information. MacPython IDE 1.0.1 >>> import sys >>> sys.path ['HD0:Applications:Programming:Python:Python 2.2.2:Mac:Tools:IDE', 'HD0:Applications:Programming:Python:Python 2.2.2:', 'HD0:Applications:Programming:Python:Python 2.2.2', 'HD0:Applications:Programming:Python:Python 2.2.2:Mac:Lib', 'HD0:Applications:Programming:Python:Python 2.2.2:Mac:Lib:lib-compat', 'HD0:Applications:Programming:Python:Python 2.2.2:Mac:Lib:lib-scriptpackages', 'HD0:Applications:Programming:Python:Python 2.2.2:Lib:lib-dynload', 'HD0:Applications:Programming:Python:Python 2.2.2:Lib', 'HD0:Applications:Programming:Python:Python 2.2.2:Lib:site-packages', 'HD0:sw:lib:python2.2:site-packages', 'HD0:sw:lib:python2.2:site-packages:Numeric', 'HD0:sw:lib:python2.2:site-packages:Scientific', 'HD0:sw:lib:python2.2:site-packages:scipy'] >>> import Numeric Traceback (most recent call last): File "", line 1, in ? File "HD0:sw:lib:python2.2:site-packages:Numeric:Numeric.py", line 91, in ? import multiarray ImportError: No module named multiarray >>> import Scientific >>> import scipy Traceback (most recent call last): File "", line 1, in ? File "HD0:sw:lib:python2.2:site-packages:scipy:__init__.py", line 36, in ? from scipy_base import * File "HD0:sw:lib:python2.2:site-packages:scipy_base:__init__.py", line 99, in ? import fastumath ImportError: No module named fastumath >>> There are no such problems when using Python from Terminal.app. What gives? I get pretty much the same thing when I just copy the relevant folders from /sw/lib/python2.2/site-packages into MacPython's site-packages folder. It looks like there's been a power surge in the transporter's pattern buffer, Cap'n. Jerry Tempe, AZ From mwh@python.net Thu Apr 3 13:32:38 2003 From: mwh@python.net (Michael Hudson) Date: Thu, 03 Apr 2003 14:32:38 +0100 Subject: [Pythonmac-SIG] Using fink 2.2's site-packages in MacPython In-Reply-To: <3243DED7-65CC-11D7-97DE-003065F93FF0@myrealbox.com> ("Lance Boyle"'s message of "Thu, 3 Apr 2003 05:02:52 -0700") References: <3243DED7-65CC-11D7-97DE-003065F93FF0@myrealbox.com> Message-ID: <2my92rr9jd.fsf@starship.python.net> "Lance Boyle" writes: > I have Python 2.2.2 working as both the "Apple" installation and the > fink installation. Included in these are packages Numeric, Scientific, > and scipy. > > Now, I want to get happy using MacPython 2.2.2. I want to make the > fink site-packages directory work with MacPython, so I use > EditPythonPrefs and add a few lines to the list of search paths > (/sw/lib/bla_bla_bla--see below). > > I'm not happy. Here's why: At a first guess, MacPython requires a different format of dynamic shared object (some kind of CFM nonsense, I presume :-) to that used by the Unix-y python you get when you type "python" in the terminal. So you need to find (or make) MacPython builds of any C extensions you want to use. Just a guess, mind. Cheers, M. -- Java is a WORA language! (Write Once, Run Away) -- James Vandenberg (on progstone@egroups.com) & quoted by David Rush on comp.lang.scheme From ryanwilcox@mac.com Thu Apr 3 14:41:39 2003 From: ryanwilcox@mac.com (Ryan Wilcox) Date: Thu, 3 Apr 2003 09:41:39 -0500 Subject: [Pythonmac-SIG] Using fink 2.2's site-packages in MacPython In-Reply-To: <3243DED7-65CC-11D7-97DE-003065F93FF0@myrealbox.com> Message-ID: On 4/3/03, at 5:02 AM, Lance Boyle said: >ow, I want to get happy using MacPython 2.2.2. I want to make the fink >site-packages directory work with MacPython, so I use EditPythonPrefs >and add a few lines to the list of search paths >(/sw/lib/bla_bla_bla--see below). Is there any real reason why you want to use MacPython? I believe using MacPython-OSX (MachOPython) would let you use your site-packages packages. I believe it has all of the same features of MacPython, AND allows you to use the unix things too. If you don't mind trying out Python 2.3, Robin Dunn has a Installer-type application on his website: http://wxpython.org/download.php If you want compatibility with OS 9 machines, you're probably in for a recompile of those packages. HTH, -Ryan Wilcox --------------------------------------------------------------------- Wilcox Design: Understanding Data http://www.wilcoxd.com From Jack.Jansen@oratrix.com Thu Apr 3 22:15:40 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Fri, 4 Apr 2003 00:15:40 +0200 Subject: [Pythonmac-SIG] Using fink 2.2's site-packages in MacPython In-Reply-To: <3243DED7-65CC-11D7-97DE-003065F93FF0@myrealbox.com> Message-ID: On donderdag, apr 3, 2003, at 14:02 Europe/Amsterdam, Lance Boyle wrote: > I have Python 2.2.2 working as both the "Apple" installation and the > fink installation. Included in these are packages Numeric, Scientific, > and scipy. > > Now, I want to get happy using MacPython 2.2.2. I want to make the > fink site-packages directory work with MacPython, so I use > EditPythonPrefs and add a few lines to the list of search paths > (/sw/lib/bla_bla_bla--see below). Michael and Ryan already answered most of the points (i.e. MacPython 2.2.X lives in a completely different universe than unix-Python 2.2.X or MacPython-2.3a2; why would you want to use MacPython 2.2.X on OSX), but there's one thing that I can't stress enough: You cannot take extension packages built for one version of Python and use them in another. When trying to import fink-Python 2.2.2 modules into MacPython 2.2.2 things fail in a benign way: it simply doesn't work. With other combinations things may appear to work, or even work partially, but you are living dangerously. There are combinations that are safe (for instance, unless either Apple or the fink people did something silly it is probably safe to use packages built for Apple's Python 2.2 in fink Python 2.2.2), but you really shouldn't do this unless you know what you are doing. And, in case you wonder why this potential problem hasn't been solved long ago: it has only really started mattering since MacOSX. Before that, Unix users almost invariably built their packages from source and for Mac and Windows there was really only one distribution. For MacOSX we suddenly have 4 things called Python, plus a user community that often prefers downloading pre-built things over building from source. As of 2.3 I hope we can get back to 2 Pythons for MacOSX: Apple's /usr/bin/python 2.2 and MacPython 2.3. Even if the fink crew decide to continue distributing a non-framework python 2.3 I hope to have the hooks in place that at least those two 2.3 Pythons will recognize each others' extension modules and complain. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From mwh@python.net Fri Apr 4 09:14:20 2003 From: mwh@python.net (Michael Hudson) Date: Fri, 04 Apr 2003 10:14:20 +0100 Subject: [Pythonmac-SIG] Using fink 2.2's site-packages in MacPython In-Reply-To: (Jack Jansen's message of "Fri, 4 Apr 2003 00:15:40 +0200") References: Message-ID: <2mel4ir5eb.fsf@starship.python.net> Jack Jansen writes: > As of 2.3 I hope we can get back to 2 Pythons for MacOSX: Apple's > /usr/bin/python 2.2 and MacPython 2.3. Do you have any idea what version of Python will ship with 10.3? Cheers, M. -- at any rate, I'm satisfied that not only do they know which end of the pointy thing to hold, but where to poke it for maximum effect. -- Eric The Read, asr, on google.com From seb@albert.vcisp.net Fri Apr 4 23:03:25 2003 From: seb@albert.vcisp.net (Sebastian Tennant) Date: Sat, 5 Apr 2003 00:03:25 +0100 Subject: [Pythonmac-SIG] A catalogue of errors !!!! Message-ID: --Apple-Mail-14-323245326 Content-Transfer-Encoding: 7bit Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Hi all. I've mistakenly installed Bob Ippolito's bundle; pygame-1.3.4-osx-kitchensink.pkg.tar, consisting of some 4000 odd files. The trouble is it is compiled to run on OS 10.2.1 and I'm running Jaguar. Stupidly I assumed 10.2.1 OR LATER! Needless to say it doesn't work and now I want to uninstall it. I've emailed Bob and he has kindly replied with the following advice: > It was compiled for 10.1. I think if you do: > > lsbom -s /Library/Receipts/pygame-1.3.4-osx-kitchensink.pkg/Archive.bom > > it will list all of the files that were installed. You could write a > script or something to delete them, but there's probably some kind of > uninstall utility available that will do this for you. I've performed the command and redirected the output so that I now have a newline delimited text file consisting of every file that was installed. (The actual .bom file is in /Library/Receipts/pygame-1.3.4-osx-kitchensink.pkg/Contents/Resources/ ). This is how I know that it consists of some 4000 odd files. I was thinking of doing something like; cat | xargs rm but on closer inspection, the text file lists parent directories on individual lines (see below) hence the above approach would be a pretty bad idea! . ./.DS_Store ./Applications ./Applications/Python.app ./Applications/Python.app/.DS_Store ./Applications/Python.app/Contents ./Applications/Python.app/Contents/.DS_Store ./Applications/Python.app/Contents/Info.plist . . . . Can anyone help, either with a shell script or an uninstall utility? Seb. --Apple-Mail-14-323245326 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII Hi all. I've mistakenly installed Bob Ippolito's bundle; 2725,110F,FFFDpygame-1.3.4-osx-kitchensink.pkg.tar0000,0000,0707, consisting of some 4000 odd files. The trouble is it is compiled to run on OS 10.2.1 and I'm running Jaguar. Stupidly I assumed 10.2.1 OR LATER! Needless to say it doesn't work and now I want to uninstall it. I've emailed Bob and he has kindly replied with the following advice: It was compiled for 10.1. I think if you do: lsbom -s /Library/Receipts/pygame-1.3.4-osx-kitchensink.pkg/Archive.bom it will list all of the files that were installed. You could write a script or something to delete them, but there's probably some kind of uninstall utility available that will do this for you.0000,0000,0707 I've performed the command and redirected the output so that I now have a newline delimited text file consisting of every file that was installed. (The actual .bom file is in /Library/Receipts/pygame-1.3.4-osx-0000,0000,0705kitchensink.pkg/Contents/Resources/). This is how I know that it consists of some 4000 odd files. I was thinking of doing something like; cat < | xargs rm but on closer inspection, the text file lists parent directories on individual lines (see below) hence the above approach would be a pretty bad idea! Courier. ./.DS_Store ./Applications ./Applications/Python.app ./Applications/Python.app/.DS_Store ./Applications/Python.app/Contents ./Applications/Python.app/Contents/.DS_Store ./Applications/Python.app/Contents/Info.plist . . . . Can anyone help, either with a shell script or an uninstall utility? Seb. --Apple-Mail-14-323245326-- From mario@ruggier.org Sat Apr 5 07:27:54 2003 From: mario@ruggier.org (Mario Ruggier) Date: Sat, 5 Apr 2003 09:27:54 +0200 Subject: [Pythonmac-SIG] python script execution strangeness Message-ID: <1D9270E8-6738-11D7-BFFF-000393756786@ruggier.org> Hi, running scripts from the command-line is behaving very strangely on my 10.2.4 system, and only one-liner scripts seem to be executed as expected. Below are an interactive session, followed by a few script examples (using '---' to visually indicate end-of-file), and their output. Whenever the python script contains more than one line, an error is reported. Plus, when I stick "#!/usr/bin/python" at the beginning of the script (one or more lines), no output (and no error) is generated. Anyone has an idea what's going on? Thanks for any help, Mario % python Python 2.2 (#1, 07/14/02, 23:25:09) [GCC Apple cpp-precomp 6.14] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> print 'something' something >>>^D % ======================= [testscript.py] print 'something'--- %python testscript.py something % ======================= [testscript.py] print 'something' --- %python testscript.py something % ======================= [testscript.py] print 'something' print 'something else' --- %python testscript.py File "", line 1 print 'something else' ^ SyntaxError: invalid syntax % ======================= [testscript.py] print 'something'; print 'something else'; --- % python testscript.py something something else % ======================= [testscript.py] print 'something' --- %python testscript.py File "", line 1 print 'something' ^ SyntaxError: invalid syntax % ======================= [testscript.py] #!/usr/bin/python print 'something' --- %python testscript.py % ======================= From just@letterror.com Sat Apr 5 09:06:43 2003 From: just@letterror.com (Just van Rossum) Date: Sat, 5 Apr 2003 11:06:43 +0200 Subject: [Pythonmac-SIG] python script execution strangeness In-Reply-To: <1D9270E8-6738-11D7-BFFF-000393756786@ruggier.org> Message-ID: Mario Ruggier wrote: > Anyone has an idea what's going on? Your files have the wrong line endings. Should be \n for the python2.2 whipped with Jaguar. From 2.2.1 and up (I think) Python is agnostic about line endings, but 2.2 is still picky. Just From mailing-l@pobox.com Mon Apr 7 05:53:16 2003 From: mailing-l@pobox.com (Bill Orcutt) Date: Sun, 06 Apr 2003 20:53:16 -0800 Subject: [Pythonmac-SIG] MP Task Threads and Embedded Python In-Reply-To: <92E8BF9E-5D6F-11D7-98AB-000A27B19B96@oratrix.com> Message-ID: Hi- I'm writing an C application for OS 9 and I need/want to call some python code from inside of an MP Task. Possible? I've had a look at the official Python thread documentation and googled and gleaned as much as I can from the web, but I still have yet find something that works. In my main thread I intialize python and threads-- << PyMac_Initialize(); PyEval_InitThreads(); // save a pointer to the main PyThreadState object mainThreadState = PyThreadState_Get(); // release the lock PyEval_ReleaseLock(); >> and then in my worker thread call-- << PyEval_AcquireLock(); // get a reference to the PyInterpreterState mainInterpreterState = mainThreadState->interp; // create a thread state object for this thread myThreadState = PyThreadState_New(mainInterpreterState); // free the lock PyEval_ReleaseLock(); // grab the global interpreter lock PyEval_AcquireLock(); // swap in my thread state PyThreadState_Swap(myThreadState); // execute some python code PyRun_SimpleString("print 'howdy-doo'"); //python here // clear the thread state PyThreadState_Swap(NULL); // release our hold on the global interpreter PyEval_ReleaseLock(); // grab the lock PyEval_AcquireLock(); // swap my thread state out of the interpreter PyThreadState_Swap(NULL); // clear out any cruft from thread state object PyThreadState_Clear(myThreadState); // delete my thread state object PyThreadState_Delete(myThreadState); // release the lock PyEval_ReleaseLock(); >> after the worker thread exits I finalize and clean up in the main thread. I've tried every permutation on this I could come up with, including a <> block and bracketing the python call with <> Clearly I'm flying blind. Any assistance or tips would be greatly appreciated. thanks Bill PS- I saw it suggested somewhere that threading is not enabled by default in MacPython- true? From owen@astro.washington.edu Mon Apr 7 17:12:02 2003 From: owen@astro.washington.edu (Russell E Owen) Date: Mon, 7 Apr 2003 09:12:02 -0700 Subject: [Pythonmac-SIG] python script execution strangeness In-Reply-To: <20030405170003.15827.12828.Mailman@mail.python.org> References: <20030405170003.15827.12828.Mailman@mail.python.org> Message-ID: Just wrote (iin reply to a question from Mario Ruggier): > > Anyone has an idea what's going on? > >Your files have the wrong line endings. Should be \n for the python2.2 >whipped with Jaguar. From 2.2.1 and up (I think) Python is agnostic >about line endings, but 2.2 is still picky. 2.2.2 is still picky about line endings. If there's a release version of unix/Mac framework Python that is not, I'd love to know about it. (I know 2.3 is such, and it's a very exciting release but it's also still alpha.) -- Russell From just@letterror.com Mon Apr 7 17:59:41 2003 From: just@letterror.com (Just van Rossum) Date: Mon, 7 Apr 2003 18:59:41 +0200 Subject: [Pythonmac-SIG] python script execution strangeness In-Reply-To: Message-ID: Russell E Owen wrote: > >Your files have the wrong line endings. Should be \n for the > >python2.2 whipped with Jaguar. From 2.2.1 and up (I think) Python is > >agnostic about line endings, but 2.2 is still picky. > > 2.2.2 is still picky about line endings. Hm, it seems you're right. I think MacPython (the non-unix, non-framework CFM-based one) might have a special hack, as arbitrary line endings do seem to work in MacPython 2.2.2. Jack probably remembers. > If there's a release version of unix/Mac framework Python that is > not, I'd love to know about it. (I know 2.3 is such, and it's a very > exciting release but it's also still alpha.) I don't think there is. Just From owen@astro.washington.edu Mon Apr 7 18:15:19 2003 From: owen@astro.washington.edu (Russell E Owen) Date: Mon, 7 Apr 2003 10:15:19 -0700 Subject: [Pythonmac-SIG] python script execution strangeness In-Reply-To: References: Message-ID: At 6:59 PM +0200 4/7/03, Just van Rossum wrote: >Russell E Owen wrote: > >> >Your files have the wrong line endings. Should be \n for the >> >python2.2 whipped with Jaguar. From 2.2.1 and up (I think) Python is >> >agnostic about line endings, but 2.2 is still picky. >> >> 2.2.2 is still picky about line endings. > >Hm, it seems you're right. I think MacPython (the non-unix, >non-framework CFM-based one) might have a special hack, as arbitrary >line endings do seem to work in MacPython 2.2.2. Jack probably >remembers. I can confirm that MacPython 2.2 (even plain 2.2; I've not yet updated my MacPython past that) handles line endings "intelligently". It is only the unix version (with or without the MacOS X framework stuff) that does not. I should have said that the first time. -- Russell P.S. For the sake of completeness, but at risk of confusing things: 2.3 will also support reading data from ordinary text files (via file open, readline, etc.) with platform-independent line endings. But I think you'll have to specify a new "u" flag to the open call to make that work. From stuart.b@commonground.com.au Tue Apr 8 07:14:55 2003 From: stuart.b@commonground.com.au (Stuart Bishop) Date: Tue, 8 Apr 2003 16:14:55 +1000 Subject: [Pythonmac-SIG] malloc debugger for OS X? Message-ID: <6A933BE4-6989-11D7-9AE8-000393B63DDC@commonground.com.au> Can anyone point me to a malloc debugger that works under OS X and can be used for tracking down 'double free' errors in Python C extensions? -- Stuart Bishop http://shangri-la.dropbear.id.au/ From mwh@python.net Tue Apr 8 10:20:16 2003 From: mwh@python.net (Michael Hudson) Date: Tue, 08 Apr 2003 10:20:16 +0100 Subject: [Pythonmac-SIG] malloc debugger for OS X? In-Reply-To: <6A933BE4-6989-11D7-9AE8-000393B63DDC@commonground.com.au> (Stuart Bishop's message of "Tue, 8 Apr 2003 16:14:55 +1000") References: <6A933BE4-6989-11D7-9AE8-000393B63DDC@commonground.com.au> Message-ID: <2mhe99pcq7.fsf@starship.python.net> Stuart Bishop writes: > Can anyone point me to a malloc debugger that works under OS X and > can be used for tracking down 'double free' errors in Python C > extensions? You could try a --pydebug build of Python 2.3 from CVS. Cheers, M. -- Well, yes. I don't think I'd put something like "penchant for anal play" and "able to wield a buttplug" in a CV unless it was relevant to the gig being applied for... -- Matt McLeod, alt.sysadmin.recovery From rafferty29@mchsi.com Tue Apr 8 13:27:06 2003 From: rafferty29@mchsi.com (Rob Bedford) Date: Tue, 8 Apr 2003 07:27:06 -0500 Subject: [Pythonmac-SIG] Pyro Error can't find nameserver Message-ID: <68F0B1FC-69BD-11D7-975C-00039374C97A@mchsi.com> Using Pyro with two different Macs I cannot find the name-server on one machine in loopback, while the other works fine. Both are running 10.2.4 however one is running Airport rather than a ethernet connection. This probably is a setting on the machine but I cannot find it. While this is not a direct Python issue I figure that this group may have experienced this and know a solution. Thanks for the help Error from terminal: Traceback (most recent call last): File "./BankServer.py", line 24, in ? ns = locator.getNS() File "/usr/lib/python2.2/site-packages/Pyro/naming.py", line 107, in getNS reply = self.sendSysCommand('location',host,port,trace) File "/usr/lib/python2.2/site-packages/Pyro/naming.py", line 100, in sendSysCommand raise errors.PyroError('Name Server not responding') Pyro.errors.PyroError: Name Server not responding And yes there is a server running in another terminal window. From jpetrone@cnri.reston.va.us Tue Apr 8 17:01:08 2003 From: jpetrone@cnri.reston.va.us (Jason Petrone) Date: Tue, 8 Apr 2003 12:01:08 -0400 Subject: [Pythonmac-SIG] malloc debugger for OS X? In-Reply-To: <6A933BE4-6989-11D7-9AE8-000393B63DDC@commonground.com.au> References: <6A933BE4-6989-11D7-9AE8-000393B63DDC@commonground.com.au> Message-ID: <20030408160108.GB18372@cnri.reston.va.us> On Tue, Apr 08, 2003 at 04:14:55PM +1000, Stuart Bishop wrote: > Can anyone point me to a malloc debugger that works under OS X and > can be used for tracking down 'double free' errors in Python C > extensions? I haven't tried using any of these on OS X, but I've used them on other unix-like platforms: valgrind dmalloc efence With the possible exception of valgrind, they shouldn't have any problems on OS X. Jason From skip@pobox.com Tue Apr 8 17:30:54 2003 From: skip@pobox.com (Skip Montanaro) Date: Tue, 8 Apr 2003 11:30:54 -0500 Subject: [Pythonmac-SIG] malloc debugger for OS X? In-Reply-To: <20030408160108.GB18372@cnri.reston.va.us> References: <6A933BE4-6989-11D7-9AE8-000393B63DDC@commonground.com.au> <20030408160108.GB18372@cnri.reston.va.us> Message-ID: <16018.63806.463626.702752@montanaro.dyndns.org> >> Can anyone point me to a malloc debugger that works under OS X and >> can be used for tracking down 'double free' errors in Python C >> extensions? Jason> I haven't tried using any of these on OS X, but I've used them on Jason> other unix-like platforms: Jason> valgrind Jason> dmalloc Jason> efence Jason> With the possible exception of valgrind, they shouldn't have any Jason> problems on OS X. None of the above three is available via fink: montanaro:skip% fink install dmalloc sudo /sw/bin/fink install dmalloc Password: Information about 2328 packages read in 1 seconds. Failed: no package found for specification 'dmalloc'! montanaro:skip% fink install efence sudo /sw/bin/fink install efence Information about 2328 packages read in 1 seconds. Failed: no package found for specification 'efence'! montanaro:skip% fink install valgrind sudo /sw/bin/fink install valgrind Information about 2328 packages read in 1 seconds. Failed: no package found for specification 'valgrind'! I would have expected them to turn up there by now if porting was no problem. Skip From jpetrone@cnri.reston.va.us Tue Apr 8 18:13:59 2003 From: jpetrone@cnri.reston.va.us (Jason Petrone) Date: Tue, 8 Apr 2003 13:13:59 -0400 Subject: [Pythonmac-SIG] malloc debugger for OS X? In-Reply-To: <16018.63806.463626.702752@montanaro.dyndns.org> References: <6A933BE4-6989-11D7-9AE8-000393B63DDC@commonground.com.au> <20030408160108.GB18372@cnri.reston.va.us> <16018.63806.463626.702752@montanaro.dyndns.org> Message-ID: <20030408171359.GC18372@cnri.reston.va.us> On Tue, Apr 08, 2003 at 11:30:54AM -0500, Skip Montanaro wrote: > > >> Can anyone point me to a malloc debugger that works under OS X and > >> can be used for tracking down 'double free' errors in Python C > >> extensions? > > Jason> I haven't tried using any of these on OS X, but I've used them on > Jason> other unix-like platforms: > > Jason> valgrind > Jason> dmalloc > Jason> efence > > Jason> With the possible exception of valgrind, they shouldn't have any > Jason> problems on OS X. > > None of the above three is available via fink: > > I would have expected them to turn up there by now if porting was no > problem. You would think so. People must like hotline clients and games more than malloc debuggers. Anyway, I just tested electric fence and it works: ------------------ test.c -------------- #include int main(int argc, char **argv) { void *a = malloc(1); free(a); free(a); return 0; } ---------------------------------------- % gcc -g test.c -L . -lefence % gdb a.out (gdb) r Starting program: /Users/jason/Desktop/downloads/ElectricFence-2.1/a.out [Switching to process 22252 thread 0xb03] Reading symbols for shared libraries . done Reading symbols for shared libraries .. done Electric Fence 2.0.5 Copyright (C) 1987-1998 Bruce Perens. ElectricFence Aborting: free(4cffc): address not from malloc(). (gdb) bt #0 0x9001b50c in kill () #1 0x00003680 in EF_Abort (pattern=0x3ec8 "free(%a): address not from malloc().") at print.c:137 #2 0x00002da4 in free (address=0x4cffc) at efence.c:632 #3 0x00001f20 in main (argc=1, argv=0xbffffd24) at test.c:6 #4 0x00001c90 in _start (argc=1, argv=0xbffffd24, envp=0xbffffd2c) at /SourceCache/Csu/Csu-45/crt.c:267 #5 0x00001b10 in start () ------------------------------------------ ... and it finds the double free in test.c line 6 I did have to make a small change to the file page.c to match OSX stdio.h and manually run ranlib on efence.a. dmalloc should work as well. it gives much more useful output, though is slightly more work to get up and going with than electric fence. jason From michael@osafoundation.org Tue Apr 8 18:26:01 2003 From: michael@osafoundation.org (Michael Toy) Date: Tue, 8 Apr 2003 10:26:01 -0700 Subject: [Pythonmac-SIG] python 2.3a2 won't build on a unix file system Message-ID: <2B23C35A-69E7-11D7-91D0-000393DBC336@osafoundation.org> I'm new to python and this list, please help me know what to do ... I was trying to figure out why python seems to build slower on macs, so just for kicks i created a unix formatted partition and tried to build os x python. the build fails, because of these lines in configure.in # Test whether we're running on a non-case-sensitive system, in which # case we give a warning if no ext is given AC_SUBST(BUILDEXEEXT) AC_MSG_CHECKING(for case-insensitive build directory) if test ! -d CaseSensitiveTestDir; then mkdir CaseSensitiveTestDir fi if test -d casesensitivetestdir then AC_MSG_RESULT(yes) BUILDEXEEXT=.exe else AC_MSG_RESULT(no) BUILDEXEEXT=$EXEEXT fi rmdir CaseSensitiveTestDir The assumption seems to be that if the file system is case in-sensitive, then we must be on an nt-box and to use .exe as an extension for binaries in the build tree, which incorrectly winds up creating "python.exe" as the built python executable if you build python on Mac OSX on an HFS+ file system. This would all be fine and dandy if all the makefiles used python$(BUILDEXEEXT), but unfortunately Mac/OSX/Makefile doesn't, it assumes the python built object is called "python.exe", but it you build on a case sensitive file system, it is caled "python", and the build fails. The real fix would probably be to change configure.in to use a some other criteria than case sensitivity to select the extension for the built python executeable, the quick fix is to fix the top level and Mac/OSX Makefiles to use $(BUILDEXEEXT). For the curious, the build ran about the same speed on the HFS file system as on the Unix file system. Do I send my diffs to someone? Does anyone even care? -Michael Toy From mwh@python.net Tue Apr 8 18:31:55 2003 From: mwh@python.net (Michael Hudson) Date: Tue, 08 Apr 2003 18:31:55 +0100 Subject: [Pythonmac-SIG] python 2.3a2 won't build on a unix file system In-Reply-To: <2B23C35A-69E7-11D7-91D0-000393DBC336@osafoundation.org> (Michael Toy's message of "Tue, 8 Apr 2003 10:26:01 -0700") References: <2B23C35A-69E7-11D7-91D0-000393DBC336@osafoundation.org> Message-ID: <2misto99pw.fsf@starship.python.net> Michael Toy writes: > I'm new to python and this list, please help me know what to do ... > > I was trying to figure out why python seems to build slower on macs, > so just for kicks i created a unix formatted partition and tried to > build os x python. > > the build fails, because of these lines in configure.in [...] > Do I send my diffs to someone? Does anyone even care? Well, you could create a patch on SF, but I guess that once the problem is pointed out, Jack will know how to deal with it without much thought. OTOH, it might help prevent the issue falling between the cracks... Cheers, M. -- MAN: How can I tell that the past isn't a fiction designed to account for the discrepancy between my immediate physical sensations and my state of mind? -- The Hitch-Hikers Guide to the Galaxy, Episode 12 From just@letterror.com Tue Apr 8 18:32:03 2003 From: just@letterror.com (Just van Rossum) Date: Tue, 8 Apr 2003 19:32:03 +0200 Subject: [Pythonmac-SIG] python 2.3a2 won't build on a unix file system In-Reply-To: <2B23C35A-69E7-11D7-91D0-000393DBC336@osafoundation.org> Message-ID: Michael Toy wrote: > Do I send my diffs to someone? Does anyone even care? It appeared to be fixed in CVS, here's log message from Makefile.pre.in: ---------------------------- revision 1.114 date: 2003/02/25 12:41:08; author: jackjansen; state: Exp; lines: +2 -0 In Mac OS X framework builds don't assume that the executable will be called python.exe but actually pass it from the main Makefile to Mac/OSX/Makefile. This makes framework builds work again on case sensitive filesystems. Fixes bug #677753. Just From kevino@tulane.edu Tue Apr 8 19:25:18 2003 From: kevino@tulane.edu (Kevin Ollivier) Date: Tue, 8 Apr 2003 11:25:18 -0700 Subject: [Pythonmac-SIG] Working with Bundlebuilder.py Message-ID: <73845D72-69EF-11D7-A34D-000393CB1C86@tulane.edu> Hi all, I've been working with the latest version of bundlebuilder.py, but recently I've been having trouble with the PyXML package. When I run the script using PythonLauncher, everything starts up fine, but when I try to run the .app bundle created by bundlebuilder.py, I'm getting errors about xml.parsers.expat.ParserCreate() not being available. I've added both _xmlplus and xml to the list of explicitly named packages to import, but with no success. (Although interestingly enough, if I add the xml package I get errors about the Sax parser not being available instead of the expat messages.) (P.S. Robin, I am not importing wxPython.xrc.) I think it actually has something to do with PyXML's import magic. It replaces the xml module with their own _xmlplus module (possibly among other things), and I think that's causing confusion during the module finding/import process. (It could even be adding xmlplus on top of the existing xml module, so at runtime they are treated as one module.) I thought it's also worth mentioning that McMillan's Installer program (which I use for the Windows version of my app) has about 9 different import hooks to make PyXML work. Is there any similar 'hooks' mechanism for Python's modulefinder.py or for bundlebuilder.py? Also, if anyone has any other Python tools for reading/writing XML that work well, and hopefully support XPath, I'm all ears. =) (Although I still want to get this import stuff fixed!) Here is the traceback: Traceback (most recent call last): File "/Users/kevino/oss/EClass/eclass_builder/build/EClass.Builder.app/ Contents/Resources/editor.py", line 2377, in ? app = MyApp(0) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- packages/wxPython/wx.py", line 1802, in __init__ _wxStart(self.OnInit) File "/Users/kevino/oss/EClass/eclass_builder/build/EClass.Builder.app/ Contents/Resources/editor.py", line 2372, in OnInit self.frame = MainFrame2(NULL, -1, "EClass.Builder") File "/Users/kevino/oss/EClass/eclass_builder/build/EClass.Builder.app/ Contents/Resources/editor.py", line 156, in __init__ self.settings.LoadFromXML(os.path.join(prefdir, "settings.xml")) File "/Users/kevino/oss/EClass/eclass_builder/conman/xml_settings.py", line 50, in LoadFromXML doc = FromXmlFile(filename) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- packages/_xmlplus/dom/ext/reader/Sax.py", line 160, in FromXmlFile saxHandlerClass, parser) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- packages/_xmlplus/dom/ext/reader/Sax.py", line 143, in FromXmlStream reader = Reader(validate, keepAllWs, catName, saxHandlerClass, parser) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- packages/_xmlplus/dom/ext/reader/Sax.py", line 118, in __init__ self.parser = parser or (validate and saxexts.XMLValParserFactory.make_parser()) or saxexts.XMLParserFactory.make_parser() File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- packages/_xmlplus/sax/saxexts.py", line 64, in make_parser return self._create_parser(parser_name) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- packages/_xmlplus/sax/saxexts.py", line 43, in _create_parser return drv_module.create_parser() File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- packages/_xmlplus/sax/drivers/drv_pyexpat.py", line 227, in create_parser return SAX_expat() File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- packages/_xmlplus/sax/drivers/drv_pyexpat.py", line 31, in __init__ self.reset() File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- packages/_xmlplus/sax/drivers/drv_pyexpat.py", line 117, in reset self.parser=expat.ParserCreate() AttributeError: 'module' object has no attribute 'ParserCreate' warning: use func(*args, **kwargs) instead of apply(func, args, kwargs) Thanks, Kevin From just@letterror.com Tue Apr 8 19:58:59 2003 From: just@letterror.com (Just van Rossum) Date: Tue, 8 Apr 2003 20:58:59 +0200 Subject: [Pythonmac-SIG] Working with Bundlebuilder.py In-Reply-To: <73845D72-69EF-11D7-A34D-000393CB1C86@tulane.edu> Message-ID: Kevin Ollivier wrote: > I've been working with the latest version of bundlebuilder.py, but > recently I've been having trouble with the PyXML package. When I run > the script using PythonLauncher, everything starts up fine, but when > I try to run the .app bundle created by bundlebuilder.py, I'm getting > errors about xml.parsers.expat.ParserCreate() not being available. > I've added both _xmlplus and xml to the list of explicitly named > packages to import, but with no success. (Although interestingly > enough, if I add the xml package I get errors about the Sax parser > not being available instead of the expat messages.) (P.S. Robin, I am > not importing wxPython.xrc.) Did you try the -v option of bundlebuilder.py? It should tell you exactly which modules got included. Perhaps this should give us a clue. Just From skip@pobox.com Tue Apr 8 20:10:13 2003 From: skip@pobox.com (Skip Montanaro) Date: Tue, 8 Apr 2003 14:10:13 -0500 Subject: [Pythonmac-SIG] python 2.3a2 won't build on a unix file system In-Reply-To: References: <2B23C35A-69E7-11D7-91D0-000393DBC336@osafoundation.org> Message-ID: <16019.7829.445266.433069@montanaro.dyndns.org> Just> Michael Toy wrote: >> Do I send my diffs to someone? Does anyone even care? Just> It appeared to be fixed in CVS, here's log message from Just> Makefile.pre.in: Wow! It would appear Jack has his own time machine. OTOH, maybe he simply borrowed Guido's last week at the Python UK Conference. Skip From just@letterror.com Tue Apr 8 20:11:24 2003 From: just@letterror.com (Just van Rossum) Date: Tue, 8 Apr 2003 21:11:24 +0200 Subject: [Pythonmac-SIG] Working with Bundlebuilder.py In-Reply-To: <73845D72-69EF-11D7-A34D-000393CB1C86@tulane.edu> Message-ID: [bundlebuilder + PyXML/Expat] Wait, here's a quick workaround, as long as it's purely expat that you're after, and not the rest of PyXML: PyXML builds pyexpat.so in .../_xmlplus/parsers/pyexpat.so. You can move pyexpat.so to the top level of site-packages (and optionally get rid of the rest of _xmlplus altogether). Just From kevino@tulane.edu Tue Apr 8 22:07:54 2003 From: kevino@tulane.edu (Kevin Ollivier) Date: Tue, 8 Apr 2003 14:07:54 -0700 Subject: [Pythonmac-SIG] Working with Bundlebuilder.py In-Reply-To: Message-ID: <2A80C84A-6A06-11D7-A34D-000393CB1C86@tulane.edu> Hi Justin, Aha! I actually do need PyXML, but this tip helped me to find the problem. When I unzipped the Modules.zip inside the Resources folder of my .app bundle, and checked inside the _xmlplus package, I noticed that the .so files (pyexpat.so and sgmlop.so) were missing from Resources/_xmlplus/parsers. When I copied them into Resources/_xmlplus/parsers, it solved the problem! It seems that when you include a package, it basically appends each submodule in the package to the importModules list, is this correct? It may be worth having it do a straight copy of the entire package instead, as in this case it missed some supporting files. Would there be any problems with using this approach? Thanks for your help! Kevin On Tuesday, April 8, 2003, at 12:11 PM, Just van Rossum wrote: > [bundlebuilder + PyXML/Expat] > > Wait, here's a quick workaround, as long as it's purely expat that > you're after, and not the rest of PyXML: PyXML builds pyexpat.so in > .../_xmlplus/parsers/pyexpat.so. You can move pyexpat.so to the top > level of site-packages (and optionally get rid of the rest of _xmlplus > altogether). > > Just > From zen@shangri-la.dropbear.id.au Wed Apr 9 04:17:34 2003 From: zen@shangri-la.dropbear.id.au (Stuart Bishop) Date: Wed, 9 Apr 2003 13:17:34 +1000 Subject: [Pythonmac-SIG] malloc debugger for OS X? In-Reply-To: <2mhe99pcq7.fsf@starship.python.net> Message-ID: On Tuesday, April 8, 2003, at 07:20 PM, Michael Hudson wrote: > Stuart Bishop writes: > >> Can anyone point me to a malloc debugger that works under OS X and >> can be used for tracking down 'double free' errors in Python C >> extensions? > > You could try a --pydebug build of Python 2.3 from CVS. I've now tried that. In this particular case, it made the warnings disappear and the program appear to run flawlessly :-) -- Stuart Bishop http://shangri-la.dropbear.id.au/ From Jack.Jansen@cwi.nl Wed Apr 9 10:46:37 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 9 Apr 2003 11:46:37 +0200 Subject: [Pythonmac-SIG] MP Task Threads and Embedded Python In-Reply-To: Message-ID: <281FA893-6A70-11D7-BC28-0030655234CE@cwi.nl> On Monday, Apr 7, 2003, at 06:53 Europe/Amsterdam, Bill Orcutt wrote: > Hi- > > I'm writing an C application for OS 9 and I need/want to call some > python > code from inside of an MP Task. I don't think so, but I'm not sure. Alexandre, do you know this? The problem is that MacPython uses GUSI for I/O, and GUSI emulates Posix threads on top of the Thread Manager. As far as I remember the Thread Manager and MP threads are mutually incompatible. You could try building (from source) a non-GUSI, non-threading MacPython, but this is probably a lot of work. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From mwh@python.net Wed Apr 9 11:33:57 2003 From: mwh@python.net (Michael Hudson) Date: Wed, 09 Apr 2003 11:33:57 +0100 Subject: [Pythonmac-SIG] malloc debugger for OS X? In-Reply-To: (Stuart Bishop's message of "Wed, 9 Apr 2003 13:17:34 +1000") References: Message-ID: <2md6jw7yei.fsf@starship.python.net> Stuart Bishop writes: > On Tuesday, April 8, 2003, at 07:20 PM, Michael Hudson wrote: > >> Stuart Bishop writes: >> >>> Can anyone point me to a malloc debugger that works under OS X and >>> can be used for tracking down 'double free' errors in Python C >>> extensions? >> >> You could try a --pydebug build of Python 2.3 from CVS. > > I've now tried that. In this particular case, it made the warnings > disappear and the program appear to run flawlessly :-) Glad to be of help :-) Does it still work with a release build? Cheers, M. -- It's relatively seldom that desire for sex is involved in technology procurement decisions. -- ESR at EuroPython 2002 From dude@cantankerouscurmudgeon.com Wed Apr 9 13:46:14 2003 From: dude@cantankerouscurmudgeon.com (The Dude) Date: Wed, 9 Apr 2003 08:46:14 -0400 Subject: [Pythonmac-SIG] newbie list? In-Reply-To: <20030409103419.16295.74732.Mailman@mail.python.org> References: <20030409103419.16295.74732.Mailman@mail.python.org> Message-ID: Folks, I am a complete newbie to python... just got my first O'Reilly text on what appears to be just what I needed in terms of a programming tool. I've lurked on your list for a few days and see a lot of over-my-head comment. Is there a newbies list you may recommend? I have an Apache-based project in mind -- basically a large CGI in Python that I would like to develop, but don't know quite where to start. I feel like this is a chicken/egg dilemma: I clearly need to know python well to know how to proceed with development, and I need to ask the right questions to learn python without undue frustration. Arrrgh. Any recommendations are most welcome. I'm on digest, so if you post here and I don't respond for a few days, it's not an insult. Thanks p From bmwblake@mac.com Wed Apr 9 15:32:23 2003 From: bmwblake@mac.com (blake smith) Date: Wed, 9 Apr 2003 09:32:23 -0500 Subject: [Pythonmac-SIG] newbie list? In-Reply-To: Message-ID: <14507F35-6A98-11D7-8D45-00039382787C@mac.com> p, i'm in pretty much the same situation, but i still lurk and read and hope that one day my skills from books will catch up to the list. you're correct, its hard to develop in a language without a full understanding, but i find it hard to get into something without a project to get me motivated. i've found the tutorials at http://www.python.org to be really helpful and give me some goals to work toward aside from the o'reilly examples. good luck. i'll be interested to see what the more experienced people on the list have to say. just wanted you to know you weren't alone in your struggle. blake smith multimedia developer nashville, tn. On Wednesday, Apr 9, 2003, at 07:46 US/Central, The Dude wrote: > Folks, > > I am a complete newbie to python... just got my first O'Reilly text on > what appears to be just what I needed in terms of a programming tool. > I've lurked on your list for a few days and see a lot of over-my-head > comment. > > Is there a newbies list you may recommend? I have an Apache-based > project in mind -- basically a large CGI in Python that I would like > to develop, but don't know quite where to start. > > I feel like this is a chicken/egg dilemma: I clearly need to know > python well to know how to proceed with development, and I need to ask > the right questions to learn python without undue frustration. Arrrgh. > > Any recommendations are most welcome. I'm on digest, so if you post > here and I don't respond for a few days, it's not an insult. > > Thanks From francois.granger@free.fr Wed Apr 9 16:31:08 2003 From: francois.granger@free.fr (Francois Granger) Date: Wed, 9 Apr 2003 17:31:08 +0200 Subject: [Pythonmac-SIG] newbie list? In-Reply-To: References: <20030409103419.16295.74732.Mailman@mail.python.org> Message-ID: At 08:46 -0400 09/04/2003, in message [Pythonmac-SIG] newbie list?, The Dude wrote: > >I am a complete newbie to python... just got my first O'Reilly text >on what appears to be just what I needed in terms of a programming >tool. I've lurked on your list for a few days and see a lot of >over-my-head comment. > >Is there a newbies list you may recommend? List-Help: List-Post: List-Subscribe: , List-Id: Discussion for learning programming with Python List-Unsubscribe: , List-Archive: -- Hofstadter's Law : It always takes longer than you expect, even when you take into account Hofstadter's Law. From landauer@got.net Wed Apr 9 16:43:26 2003 From: landauer@got.net (Doug Landauer) Date: Wed, 9 Apr 2003 08:43:26 -0700 Subject: [Pythonmac-SIG] newbie list? In-Reply-To: Message-ID: <0144C1F2-6AA2-11D7-B20C-003065E43436@got.net> On Wednesday, Apr 9, 2003, at 05:46 US/Pacific, The Dude wrote: > I am a complete newbie to python... > Is there a newbies list you may recommend? There is a Python tutorial list, though the wording of its charter appears to lean towards learning how to program, rather than towards experience programmers learning Python. I don't know how active it is, but see http://www.python.org/psa/MailingLists.html#tutor ... "This list is for folks who want to ask questions regarding how to learn computer programming with the Python language." -- Doug From jmillr@umich.edu Wed Apr 9 17:23:21 2003 From: jmillr@umich.edu (John Miller) Date: Wed, 9 Apr 2003 12:23:21 -0400 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG digest, Vol 1 #1427 - 4 msgs In-Reply-To: <20030409160004.5168.84735.Mailman@mail.python.org> Message-ID: <9442BE74-6AA7-11D7-9CDE-00039303967A@umich.edu> Google '''python cgi tutorial''' (without the quotes) and you'll be on your way... Also, be sure to put import cgitb; cgitb.enable() at the top of your script; it helps with debugging immensely! John Miller On Wednesday, April 9, 2003, at 12:00 PM, dude@cantankerouscurmudgeon.com wrote: > Is there a newbies list you may recommend? I have an Apache-based > project in mind -- basically a large CGI in Python that I would like > to develop, but don't know quite where to start. > > I feel like this is a chicken/egg dilemma: I clearly need to know > python well to know how to proceed with development, and I need to ask > the right questions to learn python without undue frustration. Arrrgh. > > Any recommendations are most welcome. I'm on digest, so if you post > here and I don't respond for a few days, it's not an insult. From mailing-l@pobox.com Wed Apr 9 17:26:56 2003 From: mailing-l@pobox.com (Bill Orcutt) Date: Wed, 09 Apr 2003 09:26:56 -0700 Subject: [Pythonmac-SIG] MP Task Threads and Embedded Python In-Reply-To: <281FA893-6A70-11D7-BC28-0030655234CE@cwi.nl> Message-ID: on 4/9/03 2:46 AM, Jack Jansen at Jack.Jansen@cwi.nl wrote: > > The problem is that MacPython uses GUSI for I/O, and GUSI emulates > Posix threads on top of the Thread Manager. As far as I remember the > Thread Manager and MP threads are mutually incompatible. The problem seems to be safety- I'm finding that my code works sometimes, but often causes terrific crashes. I'm basing my work mainly on this article: http://www.linuxjournal.com/article.php?sid=3641 which is intended for a unix/pthread audience. Well, coming at it from another angle- has anyone had any experience calling the python api from any thread (threadmanager, or other) on the classic OS? I've been hacking away at it this for nearly a week, so I'm about ready to give up and go another way, but I thought I'd send out one last SOS. Thanks for your help on this and other questions in the past. Great group. Bill From mario@ruggier.org Wed Apr 9 16:37:10 2003 From: mario@ruggier.org (Mario Ruggier) Date: Wed, 9 Apr 2003 17:37:10 +0200 Subject: [Pythonmac-SIG] newbie list? In-Reply-To: Message-ID: <209F452E-6AA1-11D7-B5D0-000393756786@ruggier.org> > Folks, > > I am a complete newbie to python... just got my first O'Reilly text on > what appears to be just what I needed in terms of a programming tool. > I've lurked on your list for a few days and see a lot of over-my-head > comment. > > Is there a newbies list you may recommend? I have an Apache-based > project in mind -- basically a large CGI in Python that I would like > to develop, but don't know quite where to start. > > I feel like this is a chicken/egg dilemma: I clearly need to know > python well to know how to proceed with development, and I need to ask > the right questions to learn python without undue frustration. Arrrgh. > > Any recommendations are most welcome. I'm on digest, so if you post > here and I don't respond for a few days, it's not an insult. > > Thanks > > p If you want large you probably do not want CGI, but any one of several _substantially_ more functional and and performant frameworks. There are several in python, and the recent posting, below, on the python-announce list, is actually a very convenient starting point to get some idea of what's out there. However, not all servers/frameworks are covered with equal attention (and note that it's author is also one of the webware authors). Regards, Mario Ruggier ======= From: Ian Bicking Date: Jeu avr 3, 2003 04:50:46 Europe/Amsterdam To: python-announce-list@python.org Subject: Paper online: "Web Framework Shootout" Since PyCon papers are perhaps best distributed in a DIY fashion, I've made my paper available at: The Web Framework Shootout http://colorstudy.com/docs/shootout.html This paper compares several web application development frameworks (CherryPy, SkunkWeb, Webware, Zope, Spyce, Albatross, jonpy, Twisted), with much of the commentary in the form of commented code examples. I hope it will help inform the Python community on some of the choices available in web development. -- Ian Bicking ianb@colorstudy.com http://colorstudy.com 4869 N. Talman Ave., Chicago, IL 60625 / 773-275-7241 "There is no flag large enough to cover the shame of killing innocent people" -- Howard Zinn From dyoo@hkn.eecs.berkeley.edu Wed Apr 9 20:40:22 2003 From: dyoo@hkn.eecs.berkeley.edu (Danny Yoo) Date: Wed, 9 Apr 2003 12:40:22 -0700 (PDT) Subject: [Pythonmac-SIG] newbie list? In-Reply-To: <0144C1F2-6AA2-11D7-B20C-003065E43436@got.net> Message-ID: On Wed, 9 Apr 2003, Doug Landauer wrote: > On Wednesday, Apr 9, 2003, at 05:46 US/Pacific, The Dude wrote: > > I am a complete newbie to python... > > Is there a newbies list you may recommend? > > There is a Python tutorial list, though the wording of its charter > appears to lean towards learning how to program, rather than towards > experience programmers learning Python. Hello! Tutor has a diverse mix of both kinds of programmers on Tutor. Please feel free to ask questions on Tutor; I'm sure that the folks there are happy to provide support as you play and learn more about Python. > I don't know how active it is, The archives at: http://mail.python.org/pipermail/tutor/ show that the size of the monthly archives have been holding steady at about 1MB zipped. Good luck to you! From zen@shangri-la.dropbear.id.au Thu Apr 10 01:30:44 2003 From: zen@shangri-la.dropbear.id.au (Stuart Bishop) Date: Thu, 10 Apr 2003 10:30:44 +1000 Subject: [Pythonmac-SIG] malloc debugger for OS X? In-Reply-To: <2md6jw7yei.fsf@starship.python.net> Message-ID: On Wednesday, April 9, 2003, at 08:33 PM, Michael Hudson wrote: > Stuart Bishop writes: > >> On Tuesday, April 8, 2003, at 07:20 PM, Michael Hudson wrote: >> >>> Stuart Bishop writes: >>> >>>> Can anyone point me to a malloc debugger that works under OS X and >>>> can be used for tracking down 'double free' errors in Python C >>>> extensions? >>> >>> You could try a --pydebug build of Python 2.3 from CVS. >> >> I've now tried that. In this particular case, it made the warnings >> disappear and the program appear to run flawlessly :-) > > Glad to be of help :-) Does it still work with a release build? No. Obviously, the library gets scared when it sees the Python debugging code and behaves itself :-) ElectricFence builds and passes the example posted here (but crashes on the example it attempts to run from the Makefile, as well as the library I'm testing). There appear to be some tools that ship with OS X I hadn't noticed before (man leaks and man malloc_history for details) that may be useful - havn't had a chance to play with these yet. -- Stuart Bishop http://shangri-la.dropbear.id.au/ From pijus@virketis.com Thu Apr 10 06:14:37 2003 From: pijus@virketis.com (Pijus Virketis) Date: Wed, 9 Apr 2003 22:14:37 -0700 Subject: [Pythonmac-SIG] newbie list? Message-ID: <533703DD-6B13-11D7-9BB4-000A9575F08A@virketis.com> Hey, > There is a Python tutorial list, though the wording of its charter > appears to lean towards learning how to program, rather than towards > experience programmers learning Python. tutor@python.org is the place to go! I actually have come the other way: after years of Python on Win32 and Linux, and many a helping hand from the folks on tutor@python.org, I've now arrived on pythonmac-sig. :) Trust me, you will not find a more helpful, patient or knowledgeable group that the guys over there. Cheers, Pijus From euphoriadj@adamswells.com Thu Apr 10 17:20:46 2003 From: euphoriadj@adamswells.com (Edd Thompson) Date: Thu, 10 Apr 2003 11:20:46 -0500 Subject: [Pythonmac-SIG] accessing .xsl files Message-ID: <62BFE5B8-6B70-11D7-9288-000393677BAE@adamswells.com> I need to get data from an excel file manipulate it and either create two new excel files or probably more easily create an html table. Is a library, module or best yet a tutorial on extracting data from an xls? And to make things worse I will be coding this on OS X but it will eventually be running on a windows NT system. From berkowit@silcom.com Thu Apr 10 17:51:20 2003 From: berkowit@silcom.com (Paul Berkowitz) Date: Thu, 10 Apr 2003 09:51:20 -0700 Subject: [Pythonmac-SIG] accessing .xsl files In-Reply-To: <62BFE5B8-6B70-11D7-9288-000393677BAE@adamswells.com> Message-ID: On 4/10/03 9:20 AM, "Edd Thompson" wrote: > I need to get data from an excel file manipulate it and either create > two new excel files or probably more easily create an html table. Is a > library, module or best yet a tutorial on extracting data from an xls? > > And to make things worse I will be coding this on OS X but it will > eventually be running > on a windows NT system. You should extract your data from the Excel file either by AppleScript or Visual Basic. If you're going to be running it on Windows then use VBA, which will be same on both if you code it in OS X. (VBA Mac is VBA 5.0 whereas the current Office VBA on Windows in VBA 6.0. Whatever works on the Mac will work on Windows, but occasionally not vice-versa.) You can account for different types of file paths on the two systems within VBA. -- Paul Berkowitz From berkowit@silcom.com Thu Apr 10 18:24:30 2003 From: berkowit@silcom.com (Paul Berkowitz) Date: Thu, 10 Apr 2003 10:24:30 -0700 Subject: [Pythonmac-SIG] accessing .xsl files In-Reply-To: Message-ID: On 4/10/03 9:51 AM, I wrote: > On 4/10/03 9:20 AM, "Edd Thompson" wrote: > >> I need to get data from an excel file manipulate it and either create >> two new excel files or probably more easily create an html table. Is a >> library, module or best yet a tutorial on extracting data from an xls? >> >> And to make things worse I will be coding this on OS X but it will >> eventually be running >> on a windows NT system. > > You should extract your data from the Excel file either by AppleScript or > Visual Basic. If you're going to be running it on Windows then use VBA, > which will be same on both if you code it in OS X. (VBA Mac is VBA 5.0 > whereas the current Office VBA on Windows in VBA 6.0. Whatever works on the > Mac will work on Windows, but occasionally not vice-versa.) You can account > for different types of file paths on the two systems within VBA. Maybe you can't do this within Excel macro itself, as an Add-In in the Startup Folder but want to do it from a self-standing app. I'm told that RealBasic can do it (both Mac and Windows identical - totally portable). -- Paul Berkowitz From TracyS.Ruggles Thu Apr 10 19:15:14 2003 From: TracyS.Ruggles (TracyS.Ruggles) Date: Thu, 10 Apr 2003 13:15:14 -0500 Subject: [Pythonmac-SIG] accessing .xsl files In-Reply-To: Message-ID: <6040BA30-6B80-11D7-9D85-000393CE1304@reinventnow.com> Is there a mac python module that could do something like this (or a module or two that I could use to create an interface like this): # --- samply.py import osax ExcelProxy = osax.Application('Microsoft Excel') # 2 options range = ExcelProxy.tell("return Range 'A1:F12' from Document 1") range = ExcelProxy.Document(1).Range('A1','F12') data = range.Value # --- end On Thursday, April 10, 2003, at 11:51 AM, Paul Berkowitz wrote: > On 4/10/03 9:20 AM, "Edd Thompson" wrote: > >> I need to get data from an excel file manipulate it and either create >> two new excel files or probably more easily create an html table. Is >> a >> library, module or best yet a tutorial on extracting data from an xls? >> >> And to make things worse I will be coding this on OS X but it will >> eventually be running >> on a windows NT system. > > You should extract your data from the Excel file either by AppleScript > or > Visual Basic. If you're going to be running it on Windows then use VBA, > which will be same on both if you code it in OS X. (VBA Mac is VBA 5.0 > whereas the current Office VBA on Windows in VBA 6.0. Whatever works > on the > Mac will work on Windows, but occasionally not vice-versa.) You can > account > for different types of file paths on the two systems within VBA. From Jack.Jansen@oratrix.com Thu Apr 10 21:11:13 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Thu, 10 Apr 2003 22:11:13 +0200 Subject: [Pythonmac-SIG] accessing .xsl files In-Reply-To: <6040BA30-6B80-11D7-9D85-000393CE1304@reinventnow.com> Message-ID: <94264F2C-6B90-11D7-9EB0-000A27B19B96@oratrix.com> On donderdag, apr 10, 2003, at 20:15 Europe/Amsterdam, Tracy S. Ruggles wrote: > Is there a mac python module that could do something like this (or a > module or two that I could use to create an interface like this): > > # --- samply.py > import osax > > ExcelProxy = osax.Application('Microsoft Excel') > # 2 options > range = ExcelProxy.tell("return Range 'A1:F12' from Document 1") > range = ExcelProxy.Document(1).Range('A1','F12') > > data = range.Value Possibly this will work with Python from CVS. I've been pounding hard on the Python OSA implementation, and the things I've tried work. But: I don't have Excel, so I can't test it. If you would be willing to get Python from the CVS repository and build the framework installation there will be (very minimal) help in the MacPython Help. Basically, first you generate the proxy module in the IDE with the new "Generate OSA Suite..." command. Tell it where excel is and it generates the interface module. Then you should be able to do something like import Excel excel = Excel.Excel() data = excel.get(Excel.Document().Range('A1:F12').Value) But: using the OSA modules with anything else than what I've tried you're threading new ground, so there's a good chance you run into bugs. But as I think OSA is very important to Python I promise to fix them quickly. And if you find enough bugs I'll add your name to the list of Python contributors:-) -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Thu Apr 10 22:15:33 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Thu, 10 Apr 2003 23:15:33 +0200 Subject: [Pythonmac-SIG] What should be on sys.path for MacPython 2.3 Message-ID: <9121A4CE-6B99-11D7-9EB0-000A27B19B96@oratrix.com> Folks, I need some feedback on one of the last design issues for MacPython 2.3. Here's the text of a bugreport I just filed (and assigned to myself:-), please let me hear of any insight you have. ------------ On MacOSX sys.path needs to conform more to the platform standard, with extensions (read: python packages) installed in multiple places (per-user, per-machine, network-wide). We can probably ignore network-wide for the time being, and per-machine is more-or-less handled by Python's lib/site-packages, but per-user is needed. Problem is that there are a number of reasonable places we could put these user-extensions: - ~/Library/Python - Perl seems to do it this way. - ~/Library/Application Support/Python - Seems like a better location - One of the above, with "site-packages" appended - allows for more stuff in there, like IDE plugins, Package Manager packages, etc. - One of the above, with $(VERSION)/site-packages appended - allows for installation of multiple Python versions without the binary extension modules getting in each others hair. And only $(VERSION) isn't even good enough if this code also gets used for non-framework Pythons, because extension modules aren't compatible between framework and non-framework builds. distutils should probably be aware of this convention, and if site-packages isn't writable to the current user fallback to the directory above (or at least give a warning explaining how to do this). For completeness we could always add the user directory to sys.path, and add the other two (/Library, /Network/Library) only if they exist. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Thu Apr 10 22:30:53 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Thu, 10 Apr 2003 23:30:53 +0200 Subject: [Pythonmac-SIG] Getting rid of BuildApplet Message-ID: Folks, I'm thinking of getting rid of BuildApplet for MacPython 2.3. The functionality is available through the IDE and through a command line tool, and I think the task isn't common enough to warrant a separate Applet in Applications->MacPython-2.3. Opinions? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From pecora@anvil.nrl.navy.mil Fri Apr 11 01:38:44 2003 From: pecora@anvil.nrl.navy.mil (Louis M. Pecora) Date: Thu, 10 Apr 2003 20:38:44 -0400 Subject: [Pythonmac-SIG] Getting rid of BuildApplet In-Reply-To: References: Message-ID: >Folks, >I'm thinking of getting rid of BuildApplet for MacPython 2.3. The functionality is available through the IDE and through a command line tool, and I think the task isn't common enough to warrant a separate Applet in Applications->MacPython-2.3. > >Opinions? Ditch it. sorry for the slang. -- Cheers, Lou Pecora From rwiser@metrowerks.com Fri Apr 11 04:37:20 2003 From: rwiser@metrowerks.com (Randy Wiser) Date: Thu, 10 Apr 2003 20:37:20 -0700 Subject: [Pythonmac-SIG] Newbie Building 2.3a2+ (framework) on OS X 10.1 gets 'Undefined symbol _CGMainDisplayID' Message-ID: <5.2.0.9.0.20030410203553.030bb008@mail.attbi.com> (Apologies if this was already posted) I've successfully built and run Python (which I checked out after 2.3 alpha 2) on OS X 10.2. Unfortunately the product is supposed to run on OS X 10.1 as well, so I'm attempting to build the same source on 10.1. Apparently Apple did not make CGMainDisplayID() available in 10.1? Thanks in advance for any ideas on how to avoid this problem (and get a good framework build on 10.1), - Randy I give the following commands and get the following error: ./configure --enable-shared --enable-framework LDFLAGS=-Wl,-x (arguments sent to configure) make building 'MacOS' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double -no-cpp-precomp -fno-common -dynamic -I. -I/Users/ctbuild/download/python.o rg/srccopy/./Include -I/Users/ctbuild/download/python.org/srccopy/./Mac/Include -I/Users/ctbuild/download/python.org/srccopy/Include -I/Us ers/ctbuild/download/python.org/srccopy -c /Users/ctbuild/download/python.org/srccopy/Mac/Modules/macosmodule.c -o build/temp.darwin-5.2.2 -Power_Macintosh-2.3/macosmodule.o In file included from /System/Library/Frameworks/CoreFoundation.framework/Headers/CFBase.h:33, from /System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:5, from /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:20, from /System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:21, from /System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:20, from /Users/ctbuild/download/python.org/srccopy/Mac/Include/macglue.h:32, from /Users/ctbuild/download/python.org/srccopy/Mac/Modules/macosmodule.c:28: /System/Library/Frameworks/CoreServices.framework/Headers/../Frameworks/CarbonCore.framework/Headers/MacTypes.h:291: warning: function dec laration isn't a prototype /System/Library/Frameworks/CoreServices.framework/Headers/../Frameworks/CarbonCore.framework/Headers/MacTypes.h:292: warning: function dec laration isn't a prototype /Users/ctbuild/download/python.org/srccopy/Mac/Modules/macosmodule.c: In function `MacOS_WMAvailable': /Users/ctbuild/download/python.org/srccopy/Mac/Modules/macosmodule.c:548: warning: implicit declaration of function `CGMainDisplayID' gcc -Wl,-x -Wl,-F. -bundle -framework Python build/temp.darwin-5.2.2-Power_Macintosh-2.3/macosmodule.o -o build/lib.darwin-5.2.2-Power_Mac intosh-2.3/MacOS.so -framework Carbon /usr/bin/ld: Undefined symbols: _CGMainDisplayID From zen@shangri-la.dropbear.id.au Fri Apr 11 08:19:52 2003 From: zen@shangri-la.dropbear.id.au (Stuart Bishop) Date: Fri, 11 Apr 2003 17:19:52 +1000 Subject: [Pythonmac-SIG] What should be on sys.path for MacPython 2.3 In-Reply-To: <9121A4CE-6B99-11D7-9EB0-000A27B19B96@oratrix.com> Message-ID: On Friday, April 11, 2003, at 07:15 AM, Jack Jansen wrote: > Problem is that there are a number of reasonable places we could put > these user-extensions: > - ~/Library/Python - Perl seems to do it this way. > - ~/Library/Application Support/Python - Seems like a better location Is ~ the logged in users home directory or the home directory of the effective uid? If it is the home directory of the logged in user, it could be a security problem if there is a python script that runs with elevated privs (oops.... PYTHONSTARTUP env variable may already allow this, unless python -E turns this feature off). If it is the home directory of the effective uid, what happens if it changes whilst a script is running? > - One of the above, with "site-packages" appended - allows for more > stuff in there, like IDE plugins, Package Manager packages, etc. > - One of the above, with $(VERSION)/site-packages appended - allows > for installation of multiple Python versions without the binary > extension modules getting in each others hair. Need at least $(VERSION). > distutils should probably be aware of this convention, and if > site-packages isn't writable to the current user fallback to the > directory above (or at least give a warning explaining how to do > > this). This could be a generic patch, substituting ~/.python for other Unixes and the Windows people might add a prefix for their platform. > For completeness we could always add the user directory to sys.path, > and add the other two (/Library, /Network/Library) only if they exist. Do we actually want /Library ? That would make two standard locations to install machine-wide site-packages. Unless of course MacPython will be installing the python libraries into /Library/Python/2.3. -- Stuart Bishop http://shangri-la.dropbear.id.au/ From Benjamin.Schollnick@usa.xerox.com Fri Apr 11 15:26:00 2003 From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin) Date: Fri, 11 Apr 2003 10:26:00 -0400 Subject: [Pythonmac-SIG] Getting rid of BuildApplet Message-ID: <51B62EFFBC83D6118ADA00096BB030A102CC2B95@usamcms7.mc.usa.xerox.com> > I'm thinking of getting rid of BuildApplet for MacPython 2.3. The > functionality is available through the IDE and through a command line > tool, and I think the task isn't common enough to warrant a separate > Applet in Applications->MacPython-2.3. BuildApplet, I've never used.... I'm not even sure the difference between it and Buildapplication.... Now BuildApplication, I'd fly over there, and hit you over the head if you even thought about removing.... At least keep it as a Python Script.... Actually, is there a reason behind having them "prebuilt", instead of just having a Alias to the scripts? - Benjamin From owen@astro.washington.edu Fri Apr 11 17:20:39 2003 From: owen@astro.washington.edu (Russell E Owen) Date: Fri, 11 Apr 2003 09:20:39 -0700 Subject: [Pythonmac-SIG] Getting rid of BuildApplet Message-ID: >I'm thinking of getting rid of BuildApplet for MacPython 2.3. The >functionality is available through the IDE and through a command >line tool, and I think the task isn't common enough to warrant a >separate Applet in Applications->MacPython-2.3. > >Opinions? If it is not too much trouble to maintain, I vote for keeping it. I personally use it frequently as I write a lot of droplets. I realize there are other ways to create them, but consider: - Folks who are building applets may not be sure what to do with the command line. Having a droplet saves explaining it. - It's an obvious paradigm. Use a droplet to create a droplet. - I confess I don't personally use the IDE. Partly this is because I do a lot of Tkinter programming (in addition to droplet programming), which it doesn't support. Partly it's because I'm quite fond of Pepper. -- Russell From rwiser@metrowerks.com Thu Apr 10 22:14:16 2003 From: rwiser@metrowerks.com (Randy Wiser) Date: Thu, 10 Apr 2003 14:14:16 -0700 Subject: [Pythonmac-SIG] Newbie Building 2.3a2+ (framework) on OS X 10.1 gets 'Undefined symbol _CGMainDisplayID' Message-ID: <5.2.0.9.0.20030410132301.070160f8@mw-aus03.mtwk.sps.mot.com> I've successfully built and run Python (which I checked out after 2.3 alpha 2) on OS X 10.2. Unfortunately the product is supposed to run on OS X 10.1 as well, so I'm attempting to build the same source on 10.1. Apparently Apple did not make CGMainDisplayID() available in 10.1? Thanks in advance for any ideas on how to avoid this problem (and get a good framework build on 10.1), - Randy I give the following commands and get the following error: ./configure --enable-shared --enable-framework LDFLAGS=-Wl,-x (arguments sent to configure) make building 'MacOS' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double -no-cpp-precomp -fno-common -dynamic -I. -I/Users/ctbuild/download/python.o rg/srccopy/./Include -I/Users/ctbuild/download/python.org/srccopy/./Mac/Include -I/Users/ctbuild/download/python.org/srccopy/Include -I/Us ers/ctbuild/download/python.org/srccopy -c /Users/ctbuild/download/python.org/srccopy/Mac/Modules/macosmodule.c -o build/temp.darwin-5.2.2 -Power_Macintosh-2.3/macosmodule.o In file included from /System/Library/Frameworks/CoreFoundation.framework/Headers/CFBase.h:33, from /System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:5, from /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:20, from /System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:21, from /System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:20, from /Users/ctbuild/download/python.org/srccopy/Mac/Include/macglue.h:32, from /Users/ctbuild/download/python.org/srccopy/Mac/Modules/macosmodule.c:28: /System/Library/Frameworks/CoreServices.framework/Headers/../Frameworks/CarbonCore.framework/Headers/MacTypes.h:291: warning: function dec laration isn't a prototype /System/Library/Frameworks/CoreServices.framework/Headers/../Frameworks/CarbonCore.framework/Headers/MacTypes.h:292: warning: function dec laration isn't a prototype /Users/ctbuild/download/python.org/srccopy/Mac/Modules/macosmodule.c: In function `MacOS_WMAvailable': /Users/ctbuild/download/python.org/srccopy/Mac/Modules/macosmodule.c:548: warning: implicit declaration of function `CGMainDisplayID' gcc -Wl,-x -Wl,-F. -bundle -framework Python build/temp.darwin-5.2.2-Power_Macintosh-2.3/macosmodule.o -o build/lib.darwin-5.2.2-Power_Mac intosh-2.3/MacOS.so -framework Carbon /usr/bin/ld: Undefined symbols: _CGMainDisplayID From oussoren@cistron.nl Sat Apr 12 17:54:49 2003 From: oussoren@cistron.nl (Ronald Oussoren) Date: Sat, 12 Apr 2003 18:54:49 +0200 Subject: [Pythonmac-SIG] accessing .xsl files In-Reply-To: <94264F2C-6B90-11D7-9EB0-000A27B19B96@oratrix.com> Message-ID: <79378BCA-6D07-11D7-98D7-0003931CFE24@cistron.nl> On Thursday, Apr 10, 2003, at 22:11 Europe/Amsterdam, Jack Jansen wrote: > Possibly this will work with Python from CVS. I've been pounding hard > on the Python OSA > implementation, and the things I've tried work. But: I don't have > Excel, so I can't test it. I have Excel, and generating the Microsoft_Excel module doesn't work (MS Office X), I get a backtrace in gensuitemodule.addmodule, specifically on line 866: Module is '' and it doesn't have an attribute named '_propdeclarations' (nor '_enumdeclarations' and '_compdeclarations'). This is using a CVS Python of about a week old. The output window of the IDE said: > ASKING FOR aete DICTIONARY IN '/Applications/Microsoft Office X/Microsoft Excel' > GetAppTerminology failed with errAEDescNotFound/resNotFound, trying manually Excell was automaticly lauched during this processes. MS Word has the same problem. Ronald From tony@lownds.com Sat Apr 12 19:28:39 2003 From: tony@lownds.com (Tony Lownds) Date: Sat, 12 Apr 2003 11:28:39 -0700 Subject: [Pythonmac-SIG] What should be on sys.path for MacPython 2.3 In-Reply-To: <9121A4CE-6B99-11D7-9EB0-000A27B19B96@oratrix.com> References: <9121A4CE-6B99-11D7-9EB0-000A27B19B96@oratrix.com> Message-ID: At 11:15 PM +0200 4/10/03, Jack Jansen wrote: >On MacOSX sys.path needs to conform more to the platform standard, >with extensions (read: python packages) installed in multiple places >(per-user, per-machine, network-wide). We can probably ignore >network-wide for the time being, and per-machine is more-or-less >handled by Python's lib/site-packages, but per-user is needed. There is no per-machine place to put platform-independent scripts though - you have to install those in two places, one for framework builds and one for non-framework builds. > >- ~/Library/Python - Perl seems to do it this way. >- ~/Library/Application Support/Python - Seems like a better location >- One of the above, with "site-packages" appended - allows for more >stuff in there, like IDE plugins, Package Manager packages, etc. >- One of the above, with $(VERSION)/site-packages appended - allows >for installation of multiple Python versions without the binary >extension modules getting in each others hair. ~/Library/Python is shorter, and there are no spaces in the path. I like the idea of having a spot for more stuff, but I also think it is more intuitive for ~/Library/Python/ to be in sys.path directly. Directories with other purposes under ~/Library/Python won't be put on the path unless there is an __init__.py file so I think it might make sense NOT to append site-packages or site-python. >distutils should probably be aware of this convention, and if >site-packages isn't writable to the current user fallback to the >directory above (or at least give a warning explaining how to do >this). > >For completeness we could always add the user directory to sys.path, >and add the other two (/Library, /Network/Library) only if they >exist. As a user I think I'd prefer distutils to install in /Library/Python/ when possible. This way it is available to CGI programs and other users without any hassle. It would seem to be most conforming to the platform standard if the order matches the framework search order: ~/Library/Python, /Library/Python, /Network/Library/Python, /System/Library/Python http://developer.apple.com/techpubs/macosx/Essentials/SystemOverview/Framewo= rks/chapter_7_section_4.html My 2=A2 -Tony From bob@heeter.net Sat Apr 12 21:58:52 2003 From: bob@heeter.net (Bob Heeter) Date: Sat, 12 Apr 2003 13:58:52 -0700 Subject: [Pythonmac-SIG] Getting rid of BuildApplet In-Reply-To: <20030411160002.15202.4567.Mailman@mail.python.org> References: <20030411160002.15202.4567.Mailman@mail.python.org> Message-ID: >I'm thinking of getting rid of BuildApplet for MacPython 2.3. The functionality is available through the IDE and through a command line tool, and I think the task isn't common enough to warrant a separate Applet in Applications->MacPython-2.3. > >Opinions? Are we only eliminating the BuildApplet applet, or are we also killing off the BuildApplet.py module? I don't mind seeing it die, but I do find it very useful and would like to know if there's an OS 9 non-IDE workaround for it, at least until I can get a new OS X box to run my stuff. I'm still using BuildApplet on a 3400-class PowerBook G3. I've never found the IDE very useful for what I need to do with Python. I need BuildApplet rather than BuildApplication because it lets me make executable top-level wrapper scripts (which are run periodically with an OS 9 implementation of Cron) and yet also allows me to frequently modify the underlying modules (around 10,000 lines of Python now) without recompiling anything. This saves me a fair amount of time and hassle. -- Bob Heeter Livermore, California From Jack.Jansen@oratrix.com Sat Apr 12 23:26:09 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 13 Apr 2003 00:26:09 +0200 Subject: [Pythonmac-SIG] accessing .xsl files In-Reply-To: <79378BCA-6D07-11D7-98D7-0003931CFE24@cistron.nl> Message-ID: On zaterdag, apr 12, 2003, at 18:54 Europe/Amsterdam, Ronald Oussoren wrote: > > On Thursday, Apr 10, 2003, at 22:11 Europe/Amsterdam, Jack Jansen > wrote: >> Possibly this will work with Python from CVS. I've been pounding hard >> on the Python OSA >> implementation, and the things I've tried work. But: I don't have >> Excel, so I can't test it. > > I have Excel, and generating the Microsoft_Excel module doesn't work > (MS Office X), I get a backtrace in gensuitemodule.addmodule, > specifically on line 866: Module is ' from /Library...>' and it doesn't have an attribute named > '_propdeclarations' (nor '_enumdeclarations' and '_compdeclarations'). > > This is using a CVS Python of about a week old. Oops, my fault. I did away with _propdeclarations, but they are indeed needed. I've fixed gensuitemodule and regenerated the suites, please do an update and try again. > The output window of the IDE said: > > ASKING FOR aete DICTIONARY IN '/Applications/Microsoft Office > X/Microsoft Excel' > > GetAppTerminology failed with errAEDescNotFound/resNotFound, trying > manually > > Excell was automaticly lauched during this processes. This seems to be how it always goes on OSX. Should I change the error message to show that the "error" is somewhat expected? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Sat Apr 12 23:36:34 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 13 Apr 2003 00:36:34 +0200 Subject: [Pythonmac-SIG] What should be on sys.path for MacPython 2.3 In-Reply-To: Message-ID: <3723A5FA-6D37-11D7-B966-000A27B19B96@oratrix.com> On zaterdag, apr 12, 2003, at 20:28 Europe/Amsterdam, Tony Lownds wrote: > ~/Library/Python is shorter, and there are no spaces in the path. I > like the idea of having a spot for more stuff, but I also think it is > more intuitive for ~/Library/Python/ to be in sys.path directly. > Directories with other purposes under ~/Library/Python won't be put > on the path unless there is an __init__.py file so I think it might > make sense NOT to append site-packages or site-python. Hmm, hmm, you have a point here (the nice and short name), but I'm not convinced yet that stuffing other directories in here is a good idea. Also, we have the version number problem, so it should at the very least be ~/Library/Python/2.3/. > As a user I think I'd prefer distutils to install in /Library/Python/ > when possible. This way it is available to CGI programs and other > users without any hassle. Are you suggesting getting rid of site-packages on sys.path altogether? Wouldn't that confuse unix-Python old-hands? > It would seem to be most conforming to the platform standard if the > order matches the framework search order: > > ~/Library/Python, /Library/Python, /Network/Library/Python, > /System/Library/Python I don't want to put /System/Library/Python there, I think it's a case of over-generality. But the other three: yes, I think that would be a good idea. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Sat Apr 12 23:37:56 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 13 Apr 2003 00:37:56 +0200 Subject: [Pythonmac-SIG] Not getting rid of BuildApplet In-Reply-To: Message-ID: <67F9DBA2-6D37-11D7-B966-000A27B19B96@oratrix.com> Enough people seem to like BuildApplet that I think we'll just keep it. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From bob@mastersofbranding.com Sun Apr 13 00:34:28 2003 From: bob@mastersofbranding.com (Bob Ippolito) Date: Sat, 12 Apr 2003 19:34:28 -0400 Subject: [Pythonmac-SIG] What should be on sys.path for MacPython 2.3 In-Reply-To: <3723A5FA-6D37-11D7-B966-000A27B19B96@oratrix.com> Message-ID: <4D87EFE2-6D3F-11D7-B675-000A95686CD8@mastersofbranding.com> On Saturday, Apr 12, 2003, at 18:36 America/New_York, Jack Jansen wrote: > > On zaterdag, apr 12, 2003, at 20:28 Europe/Amsterdam, Tony Lownds > wrote: >> ~/Library/Python is shorter, and there are no spaces in the path. I >> like the idea of having a spot for more stuff, but I also think it is >> more intuitive for ~/Library/Python/ to be in sys.path directly. >> Directories with other purposes under ~/Library/Python won't be put >> on the path unless there is an __init__.py file so I think it might >> make sense NOT to append site-packages or site-python. > > Hmm, hmm, you have a point here (the nice and short name), but I'm not > convinced yet that stuffing other directories in here is a good idea. > Also, we have the version number problem, so it should at the very > least > be ~/Library/Python/2.3/. Another thing significant to note is that Apple chooses /Library/Perl and /System/Library/Perl nomenclature for its Perl installation (I'm not sure if it supports ~/Library/Perl or /Network/Library/Perl), so we should be allowed to do the same. However, Perl is not compiled as a framework... which leaves some ambiguity in this case because Python is. >> It would seem to be most conforming to the platform standard if the >> order matches the framework search order: >> >> ~/Library/Python, /Library/Python, /Network/Library/Python, >> /System/Library/Python > > I don't want to put /System/Library/Python there, I think it's a case > of over-generality. > But the other three: yes, I think that would be a good idea. I'd make it easy for the user who is compiling Python 2.3 to decide whether they want /System/Library/Python or not. Whoever maintains Python for Apple would probably appreciate this, because that's their style, and we can all cross our fingers and hope that 2.3 will be compiled and distributed PROPERLY with OS X 10.3.X or 10.4. All of us know how messed up the Python 2.2.0 that ships with OS X 10.2.X is, and I for one never ever want to see that sort of thing happen again. Back to the "Perl is not a framework" issue, I think that we have some justification for using /System/Library/Python/VERSION as a symlink.. We have some ambiguity as far as where the heck should Python modules go? For Python to be generally useful, you need a bunch of modules. If you're going to distribute an application that has a Python framework inside it, it's highly likely that some of those modules are going to be necessary. What do we do in this case? Here's my preference (pretending I'm Apple and can use /System freely): /System/Library/Frameworks/Python.framework/Versions/VERSION/lib/ pythonVERSION should store all of the actual standard python modules /System/Library/Python/VERSION should be a symlink to the above path /Library/Python/VERSION should be the site-packages directory, /System/Library/Frameworks/Python.framework/Versions/VERSION/lib/ pythonVERSION/site-packages will symlink to this path (perhaps not necessary to add it to the search path?) ~/Library/Python/VERSION should be in the search path /Network/Library/Python/VERSION should be in the search path Basically, in this configuration, someone could just rip Python.framework out, stick it in an application bundle, and it should just work because it'll have all the standard modules it may need. site-packages goes to an easier to type and more intuitive path that can be reasonably navigated to via Finder (for drag & drop installs), and non-administrator users and network administrators can install modules into places that they have access to. Also, does distutils support this kind of configuration? Where users can install modules into some ~path, administrators can install to ~path or /path, and network admins can install to ~path /path or /Network/path? Do we need to enhance distutils, or make a mac specific extension to distutils for this? -bob From wlmyers@mac.com Sun Apr 13 01:29:15 2003 From: wlmyers@mac.com (Willard Myers) Date: Sat, 12 Apr 2003 20:29:15 -0400 Subject: [Pythonmac-SIG] Path Separator In-Reply-To: <67F9DBA2-6D37-11D7-B966-000A27B19B96@oratrix.com> Message-ID: All of the python distributions that I have tried (Apple's 2.2, 2.3a2) report ':' as the value of os.pathsep on Mac OS X. Should this not be '/' ? Bill From skip@pobox.com Sun Apr 13 01:35:22 2003 From: skip@pobox.com (Skip Montanaro) Date: Sat, 12 Apr 2003 19:35:22 -0500 Subject: [Pythonmac-SIG] Path Separator In-Reply-To: References: <67F9DBA2-6D37-11D7-B966-000A27B19B96@oratrix.com> Message-ID: <16024.45258.598078.127662@montanaro.dyndns.org> Bill> All of the python distributions that I have tried (Apple's 2.2, Bill> 2.3a2) report ':' as the value of os.pathsep on Mac OS X. Should Bill> this not be '/' ? You're thinking of os.sep, which is '/' on Mac OS X. os.pathsep is the character used to separate components of strings like the PATH environment variable. Skip From berkowit@silcom.com Sun Apr 13 20:23:05 2003 From: berkowit@silcom.com (Paul Berkowitz) Date: Sun, 13 Apr 2003 12:23:05 -0700 Subject: [Pythonmac-SIG] Can't run Python scripts from Terminal Message-ID: I'm just learning Python, and am very new still to all Unix things in OS X. I have only the default OS 10.2 installation of Python 2.2. I can run Python scripts from the Terminal when I start off with 'python filename.py' but not when I include a "#!' line and just call the filename from the same working directory, after making the file executable. Can anyone tell me what might be wrong/ More precisely, I have a perfectly (at last!) formatted Python script which I can import in the interactive command line. I can also run it perfectly from the Terminal when I am in its directory as working directory: [250-166:~/Library/Scripts/Python] berkowit% python lunch.py 'lunch.py' just runs - everything is correct as it should be. At the very top of the file, I have: #!/usr/bin/env python and I made the file executable by [250-166:~/Library/Scripts/Python] berkowit% chmod +x lunch.py (confirmed by ls -1). But when I try: [250-166:~/Library/Scripts/Python] berkowit% lunch.py lunch.py: Command not found. What's the problem? I'm sure this used to work, the last time I tried it (which was before a clean reinstall of OS 10.2). It also doesn't work if I put #!/usr/local/bin/python as the shebang line. Due to some advice here, I do have a ~/Library/init/tcsh/path file with setenv PATH "/Users/berkowit/bin/powerpc-apple-darwin:/Users/berkowit/bin:/usr/local/bin :/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/Users/berkowit/Library/Scrip ts/Python" (all one line) in it. but that's just for looking for .py files, if I remember correctly. Why is the shell not understanding my shebang line? It's not a great hardship to write 'python ' every time, but I would like to understand what's going on. -- Paul Berkowitz From mwh@python.net Sun Apr 13 21:55:29 2003 From: mwh@python.net (Michael Hudson) Date: Sun, 13 Apr 2003 21:55:29 +0100 Subject: [Pythonmac-SIG] Can't run Python scripts from Terminal In-Reply-To: (Paul Berkowitz's message of "Sun, 13 Apr 2003 12:23:05 -0700") References: Message-ID: <2m8yuep16m.fsf@starship.python.net> Paul Berkowitz writes: > [250-166:~/Library/Scripts/Python] berkowit% lunch.py > lunch.py: Command not found. '.' is not in your $PATH; try ./lunch.py instead. Cheers, M. -- Arrrrgh, the braindamage! It's not unlike the massively non-brilliant decision to use the period in abbreviations as well as a sentence terminator. Had these people no imagination at _all_? -- Erik Naggum, comp.lang.lisp From Jack.Jansen@oratrix.com Sun Apr 13 22:31:34 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 13 Apr 2003 23:31:34 +0200 Subject: [Pythonmac-SIG] Can't run Python scripts from Terminal In-Reply-To: <2m8yuep16m.fsf@starship.python.net> Message-ID: <4D18589D-6DF7-11D7-9B11-000A27B19B96@oratrix.com> On zondag, apr 13, 2003, at 22:55 Europe/Amsterdam, Michael Hudson wrote: > Paul Berkowitz writes: > >> [250-166:~/Library/Scripts/Python] berkowit% lunch.py >> lunch.py: Command not found. > > '.' is not in your $PATH; try ./lunch.py instead. I _think_ Michael is right, because you say you use out-of-the-box Python 2.2, but just for completeness sake: I had this same thing happening to me with Python 2.3 the other day, and I did have . in my path, and it even didn't work with a full pathname. After much gnashing of teeth and tearing out of hair it turned out that my file had Macintosh line separators. Python 2.3 handles any end-of-line convention, so "python file.py" works fine, but the unix kernel wants only unix end of lines, so the #! line couldn't be interpreted. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From berkowit@silcom.com Sun Apr 13 23:00:50 2003 From: berkowit@silcom.com (Paul Berkowitz) Date: Sun, 13 Apr 2003 15:00:50 -0700 Subject: [Pythonmac-SIG] Can't run Python scripts from Terminal In-Reply-To: <4D18589D-6DF7-11D7-9B11-000A27B19B96@oratrix.com> Message-ID: On 4/13/03 2:31 PM, "Jack Jansen" wrote: > On zondag, apr 13, 2003, at 22:55 Europe/Amsterdam, Michael Hudson wrote: > >> Paul Berkowitz writes: >> >>> [250-166:~/Library/Scripts/Python] berkowit% lunch.py lunch.py: Command not >>> found. >>> >> '.' is not in your $PATH; try ./lunch.py instead. >> > I _think_ Michael is right, because you say you use out-of-the-box Python > 2.2, but just for completeness sake: I had this same thing happening to me > with Python 2.3 the other day, and I did have . in my path, and it even > didn't work with a full pathname. > > After much gnashing of teeth and tearing out of hair it turned out that my > file had Macintosh line separators. Python 2.3 handles any end-of-line > convention, so "python file.py" works fine, but the unix kernel wants only > unix end of lines, so the #! line couldn't be interpreted. Yes, Michael and three people who wrote me privately earlier put me right about "." I had got too used to omitting it when using 'python'. Thanks to all of them. But now I'm back to an earlier issue. I remembered that I had once found a way to run files from the Terminal by using 'python filename' without needing to specify the full path, as long as the directory was included in PYTHONPATH. But I can't do this any more. I have made an 'environment.plist' file in an invisible ~/.MacOSX/ directory according to Russell Owen's recipe at . (I worried about Mac line endings there myself, but they are indeed Unix line-endings. Both cat in the Terminal and the Property List Editor see the separate lines.) I also have a setenv PATH in ~/Library/init/tcsh/path. No joy. I wonder what I've got wrong this time. -- Paul Berkowitz From berkowit@silcom.com Sun Apr 13 23:12:19 2003 From: berkowit@silcom.com (Paul Berkowitz) Date: Sun, 13 Apr 2003 15:12:19 -0700 Subject: [Pythonmac-SIG] Where is the sys module? Message-ID: The O'Reilly "Learning Python" tells me I should be able to get the sys module, and all its attributes, by typing dir(sys) in the interactive Python interpreter. It doesn't work (default OS 10.2 installation of Python 2.2): >>> dir(sys) Traceback (most recent call last): File "", line 1, in ? NameError: name 'sys' is not defined All my other attempts at using dir work just fine: dir(__builtins__) dir([]) etc. Just not 'sys'. This book was written when Python 1.5 was current. Has sys's name been changed in Python 2.x? Or has something else happened to it? I haven't discovered where all these built-in modules live yet. -- Paul Berkowitz From skip@pobox.com Sun Apr 13 23:37:59 2003 From: skip@pobox.com (Skip Montanaro) Date: Sun, 13 Apr 2003 17:37:59 -0500 Subject: [Pythonmac-SIG] Where is the sys module? In-Reply-To: References: Message-ID: <16025.59079.173906.555307@montanaro.dyndns.org> Paul> The O'Reilly "Learning Python" tells me I should be able to get Paul> the sys module, and all its attributes, by typing Paul> dir(sys) Paul> in the interactive Python interpreter. It doesn't work (default OS Paul> 10.2 installation of Python 2.2): I think perhaps you're misreading something. "sys" is a module, so to use it you have to import it into the current namespace. Try this instead: >>> import sys >>> dir(sys) ['__displayhook__', '__doc__', '__excepthook__', '__name__', '__stderr__', '__stdin__', '__stdout__', '_getframe', 'api_version', 'argv', 'builtin_module_names', 'byteorder', 'callstats', 'copyright', 'displayhook', 'exc_clear', 'exc_info', 'exc_type', 'excepthook', 'exec_prefix', 'executable', 'exit', 'exitfunc', 'getdefaultencoding', 'getdlopenflags', 'getfilesystemencoding', 'getrecursionlimit', 'getrefcount', 'hexversion', 'maxint', 'maxunicode', 'meta_path', 'modules', 'path', 'path_hooks', 'path_importer_cache', 'platform', 'prefix', 'ps1', 'ps2', 'setcheckinterval', 'setdlopenflags', 'setprofile', 'setrecursionlimit', 'settrace', 'stderr', 'stdin', 'stdout', 'version', 'version_info', 'warnoptions'] Skip From berkowit@silcom.com Mon Apr 14 01:11:12 2003 From: berkowit@silcom.com (Paul Berkowitz) Date: Sun, 13 Apr 2003 17:11:12 -0700 Subject: [Pythonmac-SIG] Where is the sys module? In-Reply-To: <16025.59079.173906.555307@montanaro.dyndns.org> Message-ID: On 4/13/03 3:37 PM, "Skip Montanaro" wrote: > > Paul> The O'Reilly "Learning Python" tells me I should be able to get > Paul> the sys module, and all its attributes, by typing > > Paul> dir(sys) > > Paul> in the interactive Python interpreter. It doesn't work (default OS > Paul> 10.2 installation of Python 2.2): > > I think perhaps you're misreading something. "sys" is a module, so to use > it you have to import it into the current namespace. Try this instead: > >>>> import sys >>>> dir(sys) Yes, that was it. I was misled by the fact that the first dir searches I tried were on built-ins. Thanks. -- Paul Berkowitz From berkowit@silcom.com Mon Apr 14 01:24:58 2003 From: berkowit@silcom.com (Paul Berkowitz) Date: Sun, 13 Apr 2003 17:24:58 -0700 Subject: [Pythonmac-SIG] Can't run Python scripts from Terminal In-Reply-To: Message-ID: On 4/13/03 3:00 PM, I wrote: > But now I'm back to an earlier issue. I remembered that I had once found a > way to run files from the Terminal by using 'python filename' without > needing to specify the full path, as long as the directory was included in > PYTHONPATH. But I can't do this any more. I have made an 'environment.plist' > file in an invisible ~/.MacOSX/ directory according to Russell Owen's recipe > at . (I worried about > Mac line endings there myself, but they are indeed Unix line-endings. Both > cat in the Terminal and the Property List Editor see the separate lines.) I > also have a setenv PATH in ~/Library/init/tcsh/path. No joy. I wonder what > I've got wrong this time. Well, I've discovered that Python can _import_ my own modules from that specified directory no matter where my current directory is, with just the module name, no file paths. So undoubtedly that's what at least one of those files is actually meant to accomplish. If I just give Python the file name (without full path) to run it, Python says it can't open the file, but it can import it fine in the interactive interpreter without the path. -- Paul Berkowitz From tony@lownds.com Sun Apr 13 20:20:44 2003 From: tony@lownds.com (Tony Lownds) Date: Sun, 13 Apr 2003 12:20:44 -0700 Subject: [Pythonmac-SIG] What should be on sys.path for MacPython 2.3 In-Reply-To: <3723A5FA-6D37-11D7-B966-000A27B19B96@oratrix.com> References: <3723A5FA-6D37-11D7-B966-000A27B19B96@oratrix.com> Message-ID: >Hmm, hmm, you have a point here (the nice and short name), but I'm not >convinced yet that stuffing other directories in here is a good idea. >Also, we have the version number problem, so it should at the very least >be ~/Library/Python/2.3/. With a version number in the path, where do users put version-independent modules? Or do they have to migrate them when they upgrade versions of python? For extension modules, I can definitely see the need for a per-version directory, but I also see a need for users - not just distutils and PIMP - to put files under ~/Library/Python and /Library/Python. Are there going to be separate version directories for framework and non-framework builds? >>As a user I think I'd prefer distutils to install in /Library/Python/ >>when possible. This way it is available to CGI programs and other >>users without any hassle. > >Are you suggesting getting rid of site-packages on sys.path altogether? >Wouldn't that confuse unix-Python old-hands? I'd like it if somewhere under /Library/Python could become the default distutils and PIMP installation location for darwin, framework and non-framework builds. That is a big change though. Just having them on sys.path would be great too. -Tony From bob@redivi.com Mon Apr 14 05:33:20 2003 From: bob@redivi.com (Bob Ippolito) Date: Mon, 14 Apr 2003 00:33:20 -0400 Subject: [Pythonmac-SIG] What should be on sys.path for MacPython 2.3 In-Reply-To: Message-ID: <38940AA6-6E32-11D7-B675-000A95686CD8@redivi.com> On Sunday, Apr 13, 2003, at 15:20 America/New_York, Tony Lownds wrote: > I'd like it if somewhere under /Library/Python could become the > default distutils and PIMP installation location for darwin, framework > and non-framework builds. > > That is a big change though. Just having them on sys.path would be > great too. I can't think of any good reason to have support non-framework builds (other than for Fink, which isn't the greatest reason IMHO), can you? -bob From brian_l@mac.com Mon Apr 14 06:42:56 2003 From: brian_l@mac.com (Brian Lenihan) Date: Sun, 13 Apr 2003 22:42:56 -0700 Subject: [Pythonmac-SIG] Can't run Python scripts from Terminal In-Reply-To: Message-ID: On Sunday, April 13, 2003, at 05:24 PM, Paul Berkowitz wrote: > On 4/13/03 3:00 PM, I wrote: > >> But now I'm back to an earlier issue. I remembered that I had once >> found a >> way to run files from the Terminal by using 'python filename' without >> needing to specify the full path, as long as the directory was >> included in >> PYTHONPATH. But I can't do this any more. I have made an >> 'environment.plist' >> file in an invisible ~/.MacOSX/ directory according to Russell Owen's >> recipe >> at . (I worried >> about >> Mac line endings there myself, but they are indeed Unix line-endings. >> Both >> cat in the Terminal and the Property List Editor see the separate >> lines.) I >> also have a setenv PATH in ~/Library/init/tcsh/path. No joy. I wonder >> what >> I've got wrong this time. > > > Well, I've discovered that Python can _import_ my own modules from that > specified directory no matter where my current directory is, with just > the > module name, no file paths. So undoubtedly that's what at least one of > those > files is actually meant to accomplish. If I just give Python the file > name > (without full path) to run it, Python says it can't open the file, but > it > can import it fine in the interactive interpreter without the path. What happens if you add this to the top of a file in a dir you added to your PYTHONPATH? import sys print sys.exec_prefix print sys.path Are the results what you expect, or is some other version of python trying to run your file? I ran into a strange problem recently. One that I will elaborate if you are surprised by the results of the test, above. From berkowit@silcom.com Mon Apr 14 07:05:47 2003 From: berkowit@silcom.com (Paul Berkowitz) Date: Sun, 13 Apr 2003 23:05:47 -0700 Subject: [Pythonmac-SIG] Can't run Python scripts from Terminal In-Reply-To: Message-ID: On 4/13/03 10:42 PM, "Brian Lenihan" wrote: > What happens if you add this to the top of a file in a dir you added to > your > PYTHONPATH? > > import sys > print sys.exec_prefix > print sys.path > > Are the results what you expect, or is some other version of python > trying to run your file? > I ran into a strange problem recently. One that I will elaborate if > you are surprised by the > results of the test, above. >>> import importSys /usr ['', '/Users/berkowit/Library/Scripts/Python', '/Users/berkowit', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-darwin', '/usr/lib/python2.2/lib-tk', '/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages'] It looks right to me, aside maybe from the very first ' ' in the list. What does that mean? The second path is where I'm saving my .py files, including this one. As you can see it will import with just the name, but it won't run, even when I add a shebang (#!/usr/bin/env python) at the top and make it executable. [250-166:~] berkowit% python importSys.py python: can't open file 'importSys.py' [250-166:~] berkowit% importSys.py importSys.py: Command not found. But: [250-166:~] berkowit% python ~/Library/Scripts/Python/importSys.py /usr ['/Users/berkowit/Library/Scripts/Python', '/Users/berkowit/Library/Scripts/Python', '/Users/berkowit', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-darwin', '/usr/lib/python2.2/lib-tk', '/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages'] and: [250-166:~] berkowit% ./Library/Scripts/Python/importSys.py /usr ['./Library/Scripts/Python', '/Users/berkowit/Library/Scripts/Python', '/Users/berkowit', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-darwin', '/usr/lib/python2.2/lib-tk', '/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages'] These two don't have that ' 'at the beginning. -- Paul Berkowitz From mwh@python.net Mon Apr 14 07:35:10 2003 From: mwh@python.net (Michael Hudson) Date: Mon, 14 Apr 2003 07:35:10 +0100 Subject: [Pythonmac-SIG] What should be on sys.path for MacPython 2.3 In-Reply-To: (Tony Lownds's message of "Sun, 13 Apr 2003 12:20:44 -0700") References: <3723A5FA-6D37-11D7-B966-000A27B19B96@oratrix.com> Message-ID: <2m3cklpowx.fsf@starship.python.net> Tony Lownds writes: >>Hmm, hmm, you have a point here (the nice and short name), but I'm not >>convinced yet that stuffing other directories in here is a good idea. >>Also, we have the version number problem, so it should at the very least >>be ~/Library/Python/2.3/. > > With a version number in the path, where do users put > version-independent modules? Or do they have to migrate them when they > upgrade versions of python? > For extension modules, I can definitely see the need for a per-version > directory, but I also see a need for users - not just distutils and > PIMP - to put files under ~/Library/Python and /Library/Python. Given that .pycs between (major) versions are more-or-less never copmatible, this isn't actually such a good idea. Cheers, M. -- If you have too much free time and can't think of a better way to spend it than reading Slashdot, you need a hobby, a job, or both. -- http://www.cs.washington.edu/homes/klee/misc/slashdot.html#faq From brian_l@mac.com Mon Apr 14 08:08:54 2003 From: brian_l@mac.com (Brian Lenihan) Date: Mon, 14 Apr 2003 00:08:54 -0700 Subject: [Pythonmac-SIG] Can't run Python scripts from Terminal In-Reply-To: Message-ID: On Sunday, April 13, 2003, at 11:05 PM, Paul Berkowitz wrote: > On 4/13/03 10:42 PM, "Brian Lenihan" wrote: > >> What happens if you add this to the top of a file in a dir you added >> to >> your >> PYTHONPATH? >> >> import sys >> print sys.exec_prefix >> print sys.path >> >> Are the results what you expect, or is some other version of python >> trying to run your file? >> I ran into a strange problem recently. One that I will elaborate if >> you are surprised by the >> results of the test, above. > > >>>> import importSys > /usr > ['', '/Users/berkowit/Library/Scripts/Python', '/Users/berkowit', > '/usr/lib/python2.2', '/usr/lib/python2.2/plat-darwin', > '/usr/lib/python2.2/lib-tk', '/usr/lib/python2.2/lib-dynload', > '/usr/lib/python2.2/site-packages'] > > It looks right to me, aside maybe from the very first ' ' in the list. > What > does that mean? I don't know. It's been normal behavior since the first time I noticed it. One of the core developers might know. > The second path is where I'm saving my .py files, including > this one. As you can see it will import with just the name, but it > won't > run, even when I add a shebang (#!/usr/bin/env python) at the top and > make > it executable. I wasn't very articulate, but you figured out what I meant. Good. > > [250-166:~] berkowit% python importSys.py > python: can't open file 'importSys.py' Unless you add "dot" to your default path this won't work unless you do python ./ImportSys.py > [250-166:~] berkowit% importSys.py > importSys.py: Command not found. Same here. ./importSys.py The output below won't be relevant (in the context I'm looking for) until you can run the script without specifying what should run it or where it is. > > > But: > > [250-166:~] berkowit% python ~/Library/Scripts/Python/importSys.py > /usr > ['/Users/berkowit/Library/Scripts/Python', > '/Users/berkowit/Library/Scripts/Python', '/Users/berkowit', > '/usr/lib/python2.2', '/usr/lib/python2.2/plat-darwin', > '/usr/lib/python2.2/lib-tk', '/usr/lib/python2.2/lib-dynload', > '/usr/lib/python2.2/site-packages'] [deleted other following output] From berkowit@silcom.com Mon Apr 14 08:24:06 2003 From: berkowit@silcom.com (Paul Berkowitz) Date: Mon, 14 Apr 2003 00:24:06 -0700 Subject: [Pythonmac-SIG] Can't run Python scripts from Terminal In-Reply-To: Message-ID: On 4/14/03 12:08 AM, "Brian Lenihan" wrote: >> [250-166:~] berkowit% python importSys.py >> python: can't open file 'importSys.py' > > Unless you add "dot" to your default path this won't work unless you > do python ./ImportSys.py Actual it's not in the working directory at the moment. It's in a directory where I keep all my .py files, a subfolder in my user Scripts folder. The great thing is I can now import modules from there without using the file path, just the module name, no matter where my working directory is. That's either because I have that directory included in the XML code in ~/.MacOSX/environment.plist; or else because it's in the setenv PATH specified by the ~/Library/init/tcsh/path file. I'm not sure which - I'll have to remove each in turn and log out and in to check. was kind of hoping I could also run scripts in that same directory without specifying the full path but just the file name. > >> [250-166:~] berkowit% importSys.py >> importSys.py: Command not found. > > Same here. ./importSys.py Not at the moment (same as above). > > The output below won't be relevant (in the context I'm looking for) > until > you can run the script without specifying what should run it or where > it is. > That's what's not working. -- Paul Berkowitz From Jack.Jansen@cwi.nl Mon Apr 14 10:54:43 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon, 14 Apr 2003 11:54:43 +0200 Subject: [Pythonmac-SIG] sys.path for MacPython 2.3 - next set of questions In-Reply-To: Message-ID: <1DCBCA22-6E5F-11D7-923A-0030655234CE@cwi.nl> I think I'm going to go for ~/Library/Python/2.3/site-packages, i.e. scream loudly if you *really* don't agree. There are going to be more directories in there: ~/Library/Python/2.3/IDE-scripts - Stuff for the IDE scripts menu ~/Library/Python/2.3/packman - Where pimp downloads and install dirs live These directories are only going to be used in a framework build. If non-framework grows similar functionality later it will have to use a different name for the site-packages because extension modules are incompatiple. I'm going to punt on /Library/Python for now. It doesn't offer any new functionality over $prefix/lib/python2.3/site-packages, it would only be included for completeness. Maybe we can do it with a symlink or something later on. /Network/Library/Python can also wait. But there are two more important questions that I don't have an answer to, yet. 1. Who adds ~/Library/Python/2.3/site-packages to sys.path, and when? 2. Who creates ~/Library/Python/2.3/site-packages, and when? Neither of these is obvious. For (1) the main candidate is site.py, but we only want to add it when we are running from a framework. Which means we have to import MacOS. And that's a dynamically loaded module, so it's not cheap. Should I care about this? And, if I should, any good ideas for testing whether we're in a framework install, anyone? For (2) I think either site.py or the IDE are the best choices. Note that this can't be done on installation, we're catering explicitly for the situation where admin user A has installed Python, and normal user B starts using it and wants to install her own extension modules. Site.py has the advantage that it'll also work for users only using the command line, but if creating the directory fails either it has to fail silently (leading to confusion) or you get ugly messages for every Python program run. For that reason I'm slightly in favor of doing it in the IDE. Probably distutils and pimp should also create it when needed. If we don't create the directory in site.py then there's an extra question: should it be added if it doesn't exist? I think it shouldn't, the only disadvantage would be that if you run the IDE for the first time and immediately install something with the Package Manager it will have to warn you to restart the IDE. Or the IDE has to add it manually when creating it. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From bob@redivi.com Mon Apr 14 11:56:01 2003 From: bob@redivi.com (Bob Ippolito) Date: Mon, 14 Apr 2003 06:56:01 -0400 Subject: [Pythonmac-SIG] sys.path for MacPython 2.3 - next set of questions In-Reply-To: <1DCBCA22-6E5F-11D7-923A-0030655234CE@cwi.nl> Message-ID: On Monday, Apr 14, 2003, at 05:54 America/New_York, Jack Jansen wrote: > But there are two more important questions that I don't have an answer > to, yet. > > 1. Who adds ~/Library/Python/2.3/site-packages to sys.path, and when? > 2. Who creates ~/Library/Python/2.3/site-packages, and when? > > Neither of these is obvious. For (1) the main candidate is site.py, > but we only want to add it when we are running from a framework. Which > means we have to import MacOS. And that's a dynamically loaded module, > so it's not cheap. Should I care about this? And, if I should, any > good ideas > for testing whether we're in a framework install, anyone? # sys.executable is a /usr/local/bin/python2.3 symlink >>> import os, sys >>> 'Python.framework' in os.path.realpath(sys.executable) True >>> 'Python.framework' in sys.executable False They'd have to be pretty crazy if they renamed the framework to something else. Does site.py get loaded if the interpreter is embedded in another app? If so, that potentially cause the os.path to miss... but you might not care if you're embedding python(?). -bob From Jack.Jansen@cwi.nl Mon Apr 14 13:11:38 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon, 14 Apr 2003 14:11:38 +0200 Subject: [Pythonmac-SIG] sys.path for MacPython 2.3 - next set of questions In-Reply-To: Message-ID: <3EAA7528-6E72-11D7-923A-0030655234CE@cwi.nl> On Monday, Apr 14, 2003, at 12:56 Europe/Amsterdam, Bob Ippolito wrote: > > On Monday, Apr 14, 2003, at 05:54 America/New_York, Jack Jansen wrote: > >> But there are two more important questions that I don't have an >> answer to, yet. >> >> 1. Who adds ~/Library/Python/2.3/site-packages to sys.path, and when? >> 2. Who creates ~/Library/Python/2.3/site-packages, and when? >> >> Neither of these is obvious. For (1) the main candidate is site.py, >> but we only want to add it when we are running from a framework. Which >> means we have to import MacOS. And that's a dynamically loaded module, >> so it's not cheap. Should I care about this? And, if I should, any >> good ideas >> for testing whether we're in a framework install, anyone? > > # sys.executable is a /usr/local/bin/python2.3 symlink > >>> import os, sys > >>> 'Python.framework' in os.path.realpath(sys.executable) > True > >>> 'Python.framework' in sys.executable > False This won't work for applets (try it from within the IDE in CVS-Python, for instance), which have sys.executable pointing to a symlink in their .app bundle. And this cannot be changed, as it is the magic that makes the applets connect to the window manager, find their resources, etc. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Jack.Jansen@cwi.nl Mon Apr 14 15:31:01 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon, 14 Apr 2003 16:31:01 +0200 Subject: [Pythonmac-SIG] sys.path for MacPython 2.3 - next set of questions In-Reply-To: <1DCBCA22-6E5F-11D7-923A-0030655234CE@cwi.nl> Message-ID: On Monday, Apr 14, 2003, at 11:54 Europe/Amsterdam, Jack Jansen wrote: > I think I'm going to go for ~/Library/Python/2.3/site-packages, i.e. > scream loudly > if you *really* don't agree. I just thought of a problem with the whole per-user scheme: distributions that install more than just modules. As an example, Numeric installs C header files too. This can't work (at least, not easily) for things installed per-user. I first thought that duplicating the whole Python structure (so there would be a ~/Library/Python/lib/python2.3/site-packages, but also a ~/Library/Python/include/python2.3 where Numeric can dump its include files, etc) would do the trick but it doesn't: distutils can't live with two Python "installations" so packages dependent on Numeric won't find the new include files. I'm not sure about a solution: maybe just forget about it, and let the Package Manager Manager (alias "the scapegoat") handle it, via a new warning mechanism in package descriptions ("This package needs to be installed system-wide preferably, installing it for the current user only results in reduced functionality"). -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From berkowit@silcom.com Mon Apr 14 16:11:21 2003 From: berkowit@silcom.com (Paul Berkowitz) Date: Mon, 14 Apr 2003 08:11:21 -0700 Subject: [Pythonmac-SIG] sys.path for MacPython 2.3 - next set of questions In-Reply-To: Message-ID: May I make a request as a new Python scripter? I'm probably coming from a very different place than almost everyone here who has been pioneering Python on the Mac since early days. It's natural that you are at ease with multiple Python installations and always wanting the capability of using the latest and best alpha, beta and release versions of Python. What _I_ want is a default Python installation in the next and subsequent OS versions (OS 10.3, 10.4, etc) that is optimized as far as possible. I _never_, _ever_ will ask my users to install other builds of Python. They will not do it. I want the OS-installed version of Python to be the best and latest release version at the time of OS release. For that to happen, you have to make the directory locations the ones that _Apple_ wants. Surely picking locations analogous to what they do with their mainstream programs like Perl is going to achieve that end. At the very least make them local-, not user-based. Just give yourselves an opportunity to install local-based installations for your beta and advanced work. But please make the standard installation one that can be picked up by Apple immediately after a new Python release without any fuss or bother. The only way Python will receive the widespread adoption it deserves is if good, recent versions become part of the standard OS install. If this is all beside the point, I apologize. I'm too new to Python to have any understanding of the specifics here, but am dimly aware that it may affect the OS adoption issue. Just ignore this if it's irrelevant. -- Paul Berkowitz > From: Jack Jansen > Date: Mon, 14 Apr 2003 16:31:01 +0200 > To: Jack Jansen > Cc: pythonmac-sig@python.org > Subject: Re: [Pythonmac-SIG] sys.path for MacPython 2.3 - next set of > questions > > > On Monday, Apr 14, 2003, at 11:54 Europe/Amsterdam, Jack Jansen wrote: > >> I think I'm going to go for ~/Library/Python/2.3/site-packages, i.e. >> scream loudly >> if you *really* don't agree. > > I just thought of a problem with the whole per-user scheme: > distributions that install more than just modules. As an example, > Numeric installs C header files too. This can't work (at least, not > easily) for things installed per-user. > > I first thought that duplicating the whole Python structure (so there > would be a ~/Library/Python/lib/python2.3/site-packages, but also a > ~/Library/Python/include/python2.3 where Numeric can dump its include > files, etc) would do the trick but it doesn't: distutils can't live > with two Python "installations" so packages dependent on Numeric won't > find the new include files. > > I'm not sure about a solution: maybe just forget about it, and let the > Package Manager Manager (alias "the scapegoat") handle it, via a new > warning mechanism in package descriptions ("This package needs to be > installed system-wide preferably, installing it for the current user > only results in reduced functionality"). > -- > Jack Jansen, , http://www.cwi.nl/~jack > If I can't dance I don't want to be part of your revolution -- Emma > Goldman > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From berkowit@silcom.com Mon Apr 14 16:20:56 2003 From: berkowit@silcom.com (Paul Berkowitz) Date: Mon, 14 Apr 2003 08:20:56 -0700 Subject: [Pythonmac-SIG] sys.path for MacPython 2.3 - next set of questions In-Reply-To: Message-ID: On 4/14/03 8:11 AM, I wrote: > At the very > least make them local-, not user-based. Just give yourselves an opportunity > to install local-based installations for your beta and advanced work. Sorry. I meant to say: At the very least make them LOCAL-, not user-based. Just give yourselves an opportunity to install USER-based installations for your beta and advanced work. -- Paul Berkowitz From berkowit@silcom.com Mon Apr 14 16:31:03 2003 From: berkowit@silcom.com (Paul Berkowitz) Date: Mon, 14 Apr 2003 08:31:03 -0700 Subject: [Pythonmac-SIG] Can't run Python scripts from Terminal In-Reply-To: Message-ID: On 4/14/03 8:17 AM, "Kevin Altis" wrote: > Paul, > I may not understand what problem you're trying to solve, but it seems like > you're confusing the PYTHONPATH environment variable which impacts sys.path > and the PATH environment variable which is what is used to look for programs > to run independent of Python. > > If you want to be able to run scripts regardless of which directory you're > in, then the directory that you have the scripts stored needs to be part of > your PATH environment variable; the scripts also need to be marked > executable. This is also true for the version of python or pythonw you want > to run without having to specify a full path. I have done this. And I have included that directory along with the traditional directories in a 'setenv PATH ' instruction in ~/Library/init/tcsh/path, which worked earlier. That's supposed to override the standard tcsh initializatons, but it's not doing it. This is the part that's not working. > > The PYTHONPATH environment variable is what you use to add directories to > sys.path for Python. sys.path is specifies the directories and order Python > searches for modules when you do an import. This part is working, since I made the environment.plist XML properties list file as indicated at Russell Owen's website, and put it into an invisible directory ~/.MacOSX. This works. > > Does this make sense? If so, you can post a follow-up to pythonmac-sig. Yes. You were right that I was muddling the two. PYTHONPATH is fine, it's my PATH that isn't. > > Additionally, Bill Bumgarner told me in February that: >> Anything launched from the Finder [or project builder, whatever], will >> inherit your environment.plist. >> >> Anything launched at the command line will inherit the command line >> environment which, unfortunately and by default, overrides >> environment.plist. >> >> That is broken. It should be fixed. I will try to remember to file >> a bug. That's what I've hit, I guess. I'm pretty sure that the 'setenv PATH ' instruction in ~/Library/init/tcsh/path was working to get around this bug earlier, but it isn't now. -- Paul Berkowitz From Chris.Barker@noaa.gov Sun Apr 13 12:53:48 2003 From: Chris.Barker@noaa.gov (Chris Barker) Date: Sun, 13 Apr 2003 04:53:48 -0700 Subject: [Pythonmac-SIG] sys.path for MacPython 2.3 - next set of questions References: <1DCBCA22-6E5F-11D7-923A-0030655234CE@cwi.nl> Message-ID: <3E994FCC.3537D417@noaa.gov> Jack Jansen wrote: > > I think I'm going to go for ~/Library/Python/2.3/site-packages, i.e. > scream loudly > if you *really* don't agree. This is a minor point, but it would be more like the rest of the unix world to use: whatever/Python2.3/... rather than: whatever/Python/2.3/... e.g. on linux it's all it: /usr/lib/python2.2/ Not a big deal, as long as whatever is on the seach path is python2.3, and not just "python" (with a python being a link to whatever version you might want) -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From Chris.Barker@noaa.gov Sun Apr 13 13:04:39 2003 From: Chris.Barker@noaa.gov (Chris Barker) Date: Sun, 13 Apr 2003 05:04:39 -0700 Subject: [Pythonmac-SIG] sys.path for MacPython 2.3 - next set of questions References: <1DCBCA22-6E5F-11D7-923A-0030655234CE@cwi.nl> Message-ID: <3E995257.9A28972@noaa.gov> Jack Jansen wrote: > > I think I'm going to go for ~/Library/Python/2.3/site-packages, i.e. > scream loudly > if you *really* don't agree. > I'm going to punt on /Library/Python for now. It doesn't offer any new > functionality > over $prefix/lib/python2.3/site-packages, woah! I may be missing something, but if I understand this correctly, apart from my last point (minor) it sounds like you are planning on putting site-packages in the users directory by default? That is just plain wierd. While supporting user-level installing of stuff is great, most oftern used, and default, should be system wide. Or did you mean that ~/Library/Python/2.3/site-packages Was the only one you'll do IN ADDITION to the standard system wide location. If so, then ...never mind. -Chris > 1. Who adds ~/Library/Python/2.3/site-packages to sys.path, and when? What is the harm to having it always there, even if it doesn't exist and/or has nothing in it? > 2. Who creates ~/Library/Python/2.3/site-packages, and when? > where > admin user A has installed Python, and normal user B starts using it > and wants to > install her own extension modules. This may be out of our control, but shouldn't distutils do it in that case? And if not disutils, then the user needs to vreate the directory by hand. > For that reason I'm slightly in favor of > doing it in the IDE. There are a lot of us that donm't use and probably won't ever use the IDE. Of course, we may be the same folks that don't mind typing: "mkdir ..." also. >Probably distutils and pimp should also create it when needed. Yup. Could either of those add it to the standard PythonPath when they create the directory? -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From matsakis@mit.edu Tue Apr 15 21:36:29 2003 From: matsakis@mit.edu (Nick Matsakis) Date: Tue, 15 Apr 2003 16:36:29 -0400 (EDT) Subject: [Pythonmac-SIG] Communicating With Apple In-Reply-To: <38940AA6-6E32-11D7-B675-000A95686CD8@redivi.com> References: <38940AA6-6E32-11D7-B675-000A95686CD8@redivi.com> Message-ID: On Sat, 12 Apr 2003, Bob Ippolito wrote: > I'd make it easy for the user who is compiling Python 2.3 to decide > whether they want /System/Library/Python or not. Whoever maintains > Python for Apple would probably appreciate this, because that's their > style, and we can all cross our fingers and hope that 2.3 will be > compiled and distributed PROPERLY with OS X 10.3.X or 10.4. It seem to me that this is much, much too important of an issue to just hope Apple gets right. I've already asked on this list: "_Why_ did Apple include Python with 10.2?" and it seems that no one knew the answer. I think this is a vital question and that now is the time to address it, not after Panther comes out. The reason to ask "why?" is that the answer provides a sense of where Apple is coming from. If Python was included simply as a part of Darwin, then there is no reason to expect that Pather will include anything more than a vanilla-unix Python installation since Darwin does not include the carbon frameworks or other "Mac" libraries. If it is included as a "Mac OS X" feature, then it is important to ensure that they provide a stable version where the Macpython extensions work as expected. In either case, communication with Apple at this point is important. Is anyone in a position to answer these questions? Or, is anyone who is going to WWDC willing to bring up these issues? Nick Matsakis From bob@redivi.com Tue Apr 15 21:57:27 2003 From: bob@redivi.com (Bob Ippolito) Date: Tue, 15 Apr 2003 16:57:27 -0400 Subject: [Pythonmac-SIG] Communicating With Apple In-Reply-To: Message-ID: On Tuesday, Apr 15, 2003, at 16:36 America/New_York, Nick Matsakis wrote: > On Sat, 12 Apr 2003, Bob Ippolito wrote: > >> I'd make it easy for the user who is compiling Python 2.3 to decide >> whether they want /System/Library/Python or not. Whoever maintains >> Python for Apple would probably appreciate this, because that's their >> style, and we can all cross our fingers and hope that 2.3 will be >> compiled and distributed PROPERLY with OS X 10.3.X or 10.4. > > It seem to me that this is much, much too important of an issue to just > hope Apple gets right. I've already asked on this list: "_Why_ did > Apple > include Python with 10.2?" and it seems that no one knew the answer. I > think this is a vital question and that now is the time to address it, > not > after Panther comes out. > > The reason to ask "why?" is that the answer provides a sense of where > Apple is coming from. If Python was included simply as a part of > Darwin, > then there is no reason to expect that Pather will include anything > more > than a vanilla-unix Python installation since Darwin does not include > the > carbon frameworks or other "Mac" libraries. If it is included as a > "Mac > OS X" feature, then it is important to ensure that they provide a > stable > version where the Macpython extensions work as expected. In either > case, > communication with Apple at this point is important. > > Is anyone in a position to answer these questions? Or, is anyone who > is going to WWDC willing to bring up these issues? Just to clarify, it is hardly sufficient even as a Darwin version of Python: 1) dyld The dynamic linker is busted.. it uses a completely flat namespace somehow (not related to the -flat_namespace flag), an extension named time.so in builtins is considered the same as one named pygame/time.so in another package. It recognizes that they both exist, but only ends up loading one of the two. This is a problem, and is unfixable without recompiling Python itself (dyld isn't and can't be a dynamically linked module) They _obviously_ didn't test this at all because..... 2) distutils Distutils is broken (won't compile extensions) because of the notorious -arch i386 in the Makefile.. If anyone at Apple actually used Python, they'd probably have noticed this? It also uses -flat_namespace instead of doing it -bundle_loader style, why? I modified mine to use two-level namespaces (to resolve some issues with SWIG) and bundle_loader, and it works just fine even with their broken python executable. 3) missing modules It doesn't have expat, even though expat is part of the Python source tree. Plist files are everywhere, and stock python can't parse XML without the expat module (although Twisted comes with a pure python sax-like parser and minidom replacement.. so this doesn't bother me personally too much). It doesn't have readline, which is pretty essential to using python interactively on the command line.. this can be pretty easily compiled with instructions from bbum, but come on. It doesn't have ssl support, which I guess doesn't matter so much because python's ssl module is pretty crummy compared to pyopenssl. 4) Python 2.2.0 has a lot of issues as-is Python 2.2.0 was a buggy release, it has problems with the gc module.. seems to have problems with the weakref module, and new style classes are broken in some respects (__new__ is the primary example, I think). ---- In any case, I plan on going to WWDC (I have a ticket, at least).. so perhaps I'll have the opportunity to bring up this concern. At the least, I expect (well, hope) Apple releases Panther with a clean version of Python 2.2.2 that has the above 4 issues resolved. Backports of most Macpython 2.3 modules/features are relatively trivial once you know what you're doing, but doing them to a broken Python is too much work, and sometimes you just run into things that you can't fix. -bob From larry.bugbee@boeing.com Tue Apr 15 22:04:00 2003 From: larry.bugbee@boeing.com (Bugbee, Larry) Date: Tue, 15 Apr 2003 14:04:00 -0700 Subject: [Pythonmac-SIG] Communicating With Apple Message-ID: <8CFC81BC2CC2A74F88BAB7180F00B779E0679F@XCH-NW-29.nw.nos.boeing.com> WWDC is in late June. That may be too late for Panther. Larry -----Original Message----- From: Bob Ippolito [mailto:bob@redivi.com] Sent: Tuesday, April 15, 2003 1:57 PM To: Nick Matsakis Cc: pythonmac-sig@python.org Subject: Re: [Pythonmac-SIG] Communicating With Apple On Tuesday, Apr 15, 2003, at 16:36 America/New_York, Nick Matsakis=20 wrote: > On Sat, 12 Apr 2003, Bob Ippolito wrote: > >> I'd make it easy for the user who is compiling Python 2.3 to decide >> whether they want /System/Library/Python or not. Whoever maintains >> Python for Apple would probably appreciate this, because that's their >> style, and we can all cross our fingers and hope that 2.3 will be >> compiled and distributed PROPERLY with OS X 10.3.X or 10.4. > > It seem to me that this is much, much too important of an issue to = just > hope Apple gets right. I've already asked on this list: "_Why_ did=20 > Apple > include Python with 10.2?" and it seems that no one knew the answer. I > think this is a vital question and that now is the time to address it, = > not > after Panther comes out. > > The reason to ask "why?" is that the answer provides a sense of where > Apple is coming from. If Python was included simply as a part of=20 > Darwin, > then there is no reason to expect that Pather will include anything=20 > more > than a vanilla-unix Python installation since Darwin does not include=20 > the > carbon frameworks or other "Mac" libraries. If it is included as a=20 > "Mac > OS X" feature, then it is important to ensure that they provide a=20 > stable > version where the Macpython extensions work as expected. In either=20 > case, > communication with Apple at this point is important. > > Is anyone in a position to answer these questions? Or, is anyone who > is going to WWDC willing to bring up these issues? Just to clarify, it is hardly sufficient even as a Darwin version of=20 Python: 1) dyld The dynamic linker is busted.. it uses a completely flat namespace=20 somehow (not related to the -flat_namespace flag), an extension named=20 time.so in builtins is considered the same as one named pygame/time.so=20 in another package. It recognizes that they both exist, but only ends=20 up loading one of the two. This is a problem, and is unfixable without=20 recompiling Python itself (dyld isn't and can't be a dynamically linked=20 module) They _obviously_ didn't test this at all because..... 2) distutils Distutils is broken (won't compile extensions) because of the notorious=20 -arch i386 in the Makefile.. If anyone at Apple actually used Python,=20 they'd probably have noticed this? It also uses -flat_namespace=20 instead of doing it -bundle_loader style, why? I modified mine to use=20 two-level namespaces (to resolve some issues with SWIG) and=20 bundle_loader, and it works just fine even with their broken python=20 executable. 3) missing modules It doesn't have expat, even though expat is part of the Python source=20 tree. Plist files are everywhere, and stock python can't parse XML=20 without the expat module (although Twisted comes with a pure python=20 sax-like parser and minidom replacement.. so this doesn't bother me=20 personally too much). It doesn't have readline, which is pretty essential to using python=20 interactively on the command line.. this can be pretty easily compiled=20 with instructions from bbum, but come on. It doesn't have ssl support, which I guess doesn't matter so much=20 because python's ssl module is pretty crummy compared to pyopenssl. 4) Python 2.2.0 has a lot of issues as-is Python 2.2.0 was a buggy release, it has problems with the gc module..=20 seems to have problems with the weakref module, and new style classes=20 are broken in some respects (__new__ is the primary example, I think). ---- In any case, I plan on going to WWDC (I have a ticket, at least).. so=20 perhaps I'll have the opportunity to bring up this concern. At the=20 least, I expect (well, hope) Apple releases Panther with a clean=20 version of Python 2.2.2 that has the above 4 issues resolved. =20 Backports of most Macpython 2.3 modules/features are relatively trivial=20 once you know what you're doing, but doing them to a broken Python is=20 too much work, and sometimes you just run into things that you can't=20 fix. -bob _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig From Jack.Jansen@oratrix.com Tue Apr 15 22:14:45 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Tue, 15 Apr 2003 23:14:45 +0200 Subject: [Pythonmac-SIG] Communicating With Apple In-Reply-To: Message-ID: <4844E994-6F87-11D7-9D5C-000A27B19B96@oratrix.com> On communicating with Apple: start with sending your notes/requests/questions here. There is a good chance that they'll be picked up. If you have a real bug: file it into Apple's bug reporter. This has been done for the -arch 386 bug and the missing dynamic libraries. On the version Apple includes in Panther: the big issue here is timing. As far as I can tell (from what happened with Jaguar and Python 2.2) there is a fairly early freeze for non-essential non-apple components (and Python falls into this category). Expect Panther to contain the Python that was current about half a year before Panther goes final (note: the "half a year" is purely guesswork, but that's the ballpark). That probably means that it will be 2.2.2:-( On the other issues Bob raised: - readline is always going to be a problem, because of it's GPL license. Check the archives for details. - the flat namespace cannot be fixed in the 2.2.X family because some extension packages rely on it, and micro-releases may never break existing code. Again, more details in the archives. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Tue Apr 15 22:23:01 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Tue, 15 Apr 2003 23:23:01 +0200 Subject: [Pythonmac-SIG] sys.path for MacPython 2.3 - next set of questions In-Reply-To: <3E995257.9A28972@noaa.gov> Message-ID: <701EA9AB-6F88-11D7-9D5C-000A27B19B96@oratrix.com> On zondag, apr 13, 2003, at 14:04 Europe/Amsterdam, Chris Barker wrote: >> I'm going to punt on /Library/Python for now. It doesn't offer any new >> functionality >> over $prefix/lib/python2.3/site-packages, > > woah! I may be missing something, but if I understand this correctly, > apart from my last point (minor) it sounds like you are planning on > putting site-packages in the users directory by default? No, it's going to be "in addition". I think it's going to be first $prefix/lib/python2.3/site-packages, then ~/Library/Python/2.3/site-packages. The standard Pythonic rule seems to be "don't override, only extend". >> 1. Who adds ~/Library/Python/2.3/site-packages to sys.path, and when? > > What is the harm to having it always there, even if it doesn't exist > and/or has nothing in it? Turns out it doesn't matter: site.py will remove it if it doesn't exist. >> 2. Who creates ~/Library/Python/2.3/site-packages, and when? > >> where >> admin user A has installed Python, and normal user B starts using it >> and wants to >> install her own extension modules. > > This may be out of our control, but shouldn't distutils do it in that > case? And if not disutils, then the user needs to vreate the directory > by hand. After some thought I'm not going to muck with distutils, I'm going to do it in Package Manager. It will call setup.py with the right arguments to deposit things in the right location. People using pimp (the tool underlying Package Manager) from the command line can specify the directory by hand. Package Manager is going to get a radio button for "Install system-wide"/ "For current user only" (can anyone think of two nice short labels for this?), and system-wide is going to be disabled if you don't have write-access to $prefix/lib/python2.3/site-packages. If you install for yourself only and this results in reduced functionality for the package you will get a warning. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Tue Apr 15 22:24:07 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Tue, 15 Apr 2003 23:24:07 +0200 Subject: [Pythonmac-SIG] sys.path for MacPython 2.3 - next set of questions In-Reply-To: <3E994FCC.3537D417@noaa.gov> Message-ID: <97120884-6F88-11D7-9D5C-000A27B19B96@oratrix.com> On zondag, apr 13, 2003, at 13:53 Europe/Amsterdam, Chris Barker wrote: > Jack Jansen wrote: >> >> I think I'm going to go for ~/Library/Python/2.3/site-packages, i.e. >> scream loudly >> if you *really* don't agree. > > This is a minor point, but it would be more like the rest of the unix > world to use: > > whatever/Python2.3/... > > rather than: > > whatever/Python/2.3/... I pondered this for a while, but I think "2.3" is better in this case. ~/Library is a MacOSX thingy, so we should follow MacOSX conventions, not Python conventions. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From just@letterror.com Tue Apr 15 22:26:43 2003 From: just@letterror.com (Just van Rossum) Date: Tue, 15 Apr 2003 23:26:43 +0200 Subject: [Pythonmac-SIG] sys.path for MacPython 2.3 - next set of questions In-Reply-To: <701EA9AB-6F88-11D7-9D5C-000A27B19B96@oratrix.com> Message-ID: Jack Jansen wrote: > Turns out it doesn't matter: site.py will remove it if it doesn't > exist. Not anymore in 2.3. Just From bob@redivi.com Tue Apr 15 22:31:42 2003 From: bob@redivi.com (Bob Ippolito) Date: Tue, 15 Apr 2003 17:31:42 -0400 Subject: [Pythonmac-SIG] Communicating With Apple In-Reply-To: <4844E994-6F87-11D7-9D5C-000A27B19B96@oratrix.com> Message-ID: On Tuesday, Apr 15, 2003, at 17:14 America/New_York, Jack Jansen wrote: > On the other issues Bob raised: > - readline is always going to be a problem, because of it's GPL > license. > Check the archives for details. Can we go ahead and include something like pyrepl (http://starship.python.net/crew/mwh/hacks/pyrepl.html) instead? Or hack in libedit support instead (non-mac python could benefit from this as well)? I know we talked about this briefly on the list last year, but I don't think anyone really said or did anything about it. -bob From Jack.Jansen@oratrix.com Tue Apr 15 22:33:35 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Tue, 15 Apr 2003 23:33:35 +0200 Subject: [Pythonmac-SIG] sys.path for MacPython 2.3 - next set of questions In-Reply-To: Message-ID: Paul, don't worry: this is exactly what we're trying to do, make MacPython 2.3 so comfortable to both Mac-heads and Unix-heads that there really is no reason to use anything else. The bad news about standard inclusion by Apple, however, is timing. I don't expect to see MacPython 2.3 as part of 10.3, see my other message of tonight for why not. So for 2.3 one of my concerns is making sure MacPython 2.3 and any other Python (either Apple-installed or user-installed) are not going to bite each other, perhaps even cooperate, and at the very least cause as little user confusion as possible. And: definitely keep the comments coming. There's enough unix-expertise and MacOS9-Python expertise here so that we won't make too many bad mistakes in that area (cross fingers), but what we're *really* after is the new converts like yourself. On maandag, apr 14, 2003, at 17:11 Europe/Amsterdam, Paul Berkowitz wrote: > May I make a request as a new Python scripter? I'm probably coming > from a > very different place than almost everyone here who has been pioneering > Python on the Mac since early days. It's natural that you are at ease > with > multiple Python installations and always wanting the capability of > using the > latest and best alpha, beta and release versions of Python. > > What _I_ want is a default Python installation in the next and > subsequent OS > versions (OS 10.3, 10.4, etc) that is optimized as far as possible. I > _never_, _ever_ will ask my users to install other builds of Python. > They > will not do it. I want the OS-installed version of Python to be the > best and > latest release version at the time of OS release. > > For that to happen, you have to make the directory locations the ones > that > _Apple_ wants. Surely picking locations analogous to what they do with > their > mainstream programs like Perl is going to achieve that end. At the very > least make them local-, not user-based. Just give yourselves an > opportunity > to install local-based installations for your beta and advanced work. > But > please make the standard installation one that can be picked up by > Apple > immediately after a new Python release without any fuss or bother. > > The only way Python will receive the widespread adoption it deserves > is if > good, recent versions become part of the standard OS install. > > If this is all beside the point, I apologize. I'm too new to Python to > have > any understanding of the specifics here, but am dimly aware that it may > affect the OS adoption issue. Just ignore this if it's irrelevant. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From matsakis@mit.edu Tue Apr 15 22:39:54 2003 From: matsakis@mit.edu (Nick Matsakis) Date: Tue, 15 Apr 2003 17:39:54 -0400 (EDT) Subject: [Pythonmac-SIG] Communicating With Apple In-Reply-To: <4844E994-6F87-11D7-9D5C-000A27B19B96@oratrix.com> References: <4844E994-6F87-11D7-9D5C-000A27B19B96@oratrix.com> Message-ID: On Tue, 15 Apr 2003, Jack Jansen wrote: > On the version Apple includes in Panther: the big issue here is timing. > ... Expect Panther to contain the Python that was current about half a > year before Panther goes final (note: the "half a year" is purely > guesswork, but that's the ballpark). That probably means that it will be > 2.2.2:-( So, will this be a vanilla unix python, or Macpython 2.2.2? In other words, would the Carbon/Mac modules be included? If not, would the installed version be compatible with their inclusion in a separate framework? (i.e. one that could be included in an application package or dragged into the appropriate folder). http://www.opensource.apple.com/darwinsource/10.2.5/python/ It seems like committing Python to the Darwin source tree would be sufficient for eventual inclusion in OS X. Perhaps it would be worth getting a stable 2.2 Macpython committed? (if it isn't already). Nick Matsakis From mwh@python.net Tue Apr 15 22:46:02 2003 From: mwh@python.net (Michael Hudson) Date: Tue, 15 Apr 2003 22:46:02 +0100 Subject: [Pythonmac-SIG] Communicating With Apple In-Reply-To: (Bob Ippolito's message of "Tue, 15 Apr 2003 17:31:42 -0400") References: Message-ID: <2mk7dvph7p.fsf@starship.python.net> Bob Ippolito writes: > On Tuesday, Apr 15, 2003, at 17:14 America/New_York, Jack Jansen wrote: > >> On the other issues Bob raised: >> - readline is always going to be a problem, because of it's GPL >> license. >> Check the archives for details. > > Can we go ahead and include something like pyrepl > (http://starship.python.net/crew/mwh/hacks/pyrepl.html) instead? pyrepl is not sufficiently mature to inflict on people who don't expect it :-) Actually, I should get off my arse and do a new release soon -- what's in CVS is somewhat better than the last release -- and then finally check in the unicode support. Thanks for the plug, though :-) > Or hack in libedit support instead (non-mac python could benefit > from this as well)? This has been suggested before -- I believe the phrase "patches welcome", you'll no doubt be surprised to hear... Cheers, M. -- > You're already using asyncore so you can't really be worried > about complexity . (-8 .helps which, demand on backwards work to brain my rewired I've -- Jeremy Hylton & Richie Hindle From mwh@python.net Tue Apr 15 22:54:56 2003 From: mwh@python.net (Michael Hudson) Date: Tue, 15 Apr 2003 22:54:56 +0100 Subject: [Pythonmac-SIG] Communicating With Apple In-Reply-To: (Nick Matsakis's message of "Tue, 15 Apr 2003 17:39:54 -0400 (EDT)") References: <4844E994-6F87-11D7-9D5C-000A27B19B96@oratrix.com> Message-ID: <2mhe8zpgsv.fsf@starship.python.net> Nick Matsakis writes: > On Tue, 15 Apr 2003, Jack Jansen wrote: > >> On the version Apple includes in Panther: the big issue here is timing. >> ... Expect Panther to contain the Python that was current about half a >> year before Panther goes final (note: the "half a year" is purely >> guesswork, but that's the ballpark). That probably means that it will be >> 2.2.2:-( > > So, will this be a vanilla unix python, or Macpython 2.2.2? In other > words, would the Carbon/Mac modules be included? I *think* the diffuculty is that Python is considered to be part of Darwin, and so doesn't "see" the Mac side of things... hard to compile _Res.c when there's no Carbon.framework. I could be wrong, and would dearly like to be... Cheers, M. -- SPIDER: 'Scuse me. [scuttles off] ZAPHOD: One huge spider. FORD: Polite though. -- The Hitch-Hikers Guide to the Galaxy, Episode 11 From bob@redivi.com Tue Apr 15 23:34:27 2003 From: bob@redivi.com (Bob Ippolito) Date: Tue, 15 Apr 2003 18:34:27 -0400 Subject: [Pythonmac-SIG] Communicating With Apple In-Reply-To: <2mhe8zpgsv.fsf@starship.python.net> Message-ID: <6ADD0880-6F92-11D7-AE87-000A95686CD8@redivi.com> On Tuesday, Apr 15, 2003, at 17:54 America/New_York, Michael Hudson wrote: > Nick Matsakis writes: > >> On Tue, 15 Apr 2003, Jack Jansen wrote: >> >>> On the version Apple includes in Panther: the big issue here is >>> timing. >>> ... Expect Panther to contain the Python that was current about half >>> a >>> year before Panther goes final (note: the "half a year" is purely >>> guesswork, but that's the ballpark). That probably means that it >>> will be >>> 2.2.2:-( >> >> So, will this be a vanilla unix python, or Macpython 2.2.2? In other >> words, would the Carbon/Mac modules be included? > > I *think* the diffuculty is that Python is considered to be part of > Darwin, and so doesn't "see" the Mac side of things... hard to compile > _Res.c when there's no Carbon.framework. > > I could be wrong, and would dearly like to be... It's *possible* to backport these modules to whichever distribution of Python Apple decides to give us (considering I have them more or less all working on Apple's 2.2.0, I doubt it could be any worse).. It'd just be convenient if batteries were included. -bob From Chris.Barker@noaa.gov Tue Apr 15 23:43:31 2003 From: Chris.Barker@noaa.gov (Chris Barker) Date: Tue, 15 Apr 2003 15:43:31 -0700 Subject: [Pythonmac-SIG] sys.path for MacPython 2.3 - next set of questions References: Message-ID: <3E9C8B13.C7EDF54D@noaa.gov> Just van Rossum wrote: > > Turns out it doesn't matter: site.py will remove it if it doesn't > > exist. > > Not anymore in 2.3. So what does 2.3 do with directories on PYTHONPATH that don't exist? -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From just@letterror.com Wed Apr 16 00:05:43 2003 From: just@letterror.com (Just van Rossum) Date: Wed, 16 Apr 2003 01:05:43 +0200 Subject: [Pythonmac-SIG] sys.path for MacPython 2.3 - next set of questions In-Reply-To: <3E9C8B13.C7EDF54D@noaa.gov> Message-ID: Chris Barker wrote: > Just van Rossum wrote: > > > Turns out it doesn't matter: site.py will remove it if it doesn't > > > exist. > > > > Not anymore in 2.3. > > So what does 2.3 do with directories on PYTHONPATH that don't exist? Nothing, it leaves them in. The idea is that there may be importer objects on sys.path_hooks that can handle them (see PEP 302). Just From jwblist@olympus.net Wed Apr 16 02:40:53 2003 From: jwblist@olympus.net (John W Baxter) Date: Tue, 15 Apr 2003 18:40:53 -0700 Subject: [Pythonmac-SIG] What should be on sys.path for MacPython 2.3 In-Reply-To: <3723A5FA-6D37-11D7-B966-000A27B19B96@oratrix.com> References: <3723A5FA-6D37-11D7-B966-000A27B19B96@oratrix.com> Message-ID: At 0:36 +0200 4/13/2003, Jack Jansen wrote: >I don't want to put /System/Library/Python there, I think it's a case >of over-generality. >But the other three: yes, I think that would be a good idea. This is where Apple would put stuff they don't want users messing with. But that observation doesn't help much if at all, since I don't know whether Apple feels there are any such things in Python. --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From Jack.Jansen@cwi.nl Wed Apr 16 10:32:42 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 16 Apr 2003 11:32:42 +0200 Subject: [Pythonmac-SIG] Communicating With Apple In-Reply-To: <2mhe8zpgsv.fsf@starship.python.net> Message-ID: <5F5D511A-6FEE-11D7-9513-0030655234CE@cwi.nl> On Tuesday, Apr 15, 2003, at 23:54 Europe/Amsterdam, Michael Hudson wrote: >> So, will this be a vanilla unix python, or Macpython 2.2.2? In other >> words, would the Carbon/Mac modules be included? > > I *think* the diffuculty is that Python is considered to be part of > Darwin, and so doesn't "see" the Mac side of things... hard to compile > _Res.c when there's no Carbon.framework. That's not the problem. Look in your /usr/lib/python2.2/lib-dynload, you'll see all the MacPython extension modules there. The bad news is that they're next to useless. The whole Mac subtree is missing, and Mac/Lib is where all the goodies were under 2.2. And even if the Mac subtree was there there are lots of other problems. For one thing, all the modules use Mac :-style pathnames. I started on some hooks to do a MacPython-OSX 2.2.X add-on distribution (look in the CVS tree in Mac/OSX, anything with "jaguar" in the name), and I got quite a couple of things working, but 2.3 is really taking up all my time, and I think it is more important to get a really hot 2.3 distribution than spend time on a 2.2 addon that will have a limited lifetime anyway. Oh yes, this doesn't live in the 2.2 branch but in the main branch. The idea was to take the Mac 2.3 portion and graft it onto unix 2.2. If anyone wants to revive it it'll need serious surgery, not in the least because Mac/Lib has moved to Lib/plat-mac. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Jack.Jansen@cwi.nl Wed Apr 16 10:34:21 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 16 Apr 2003 11:34:21 +0200 Subject: [Pythonmac-SIG] sys.path for MacPython 2.3 - next set of questions In-Reply-To: Message-ID: <9ABED7C8-6FEE-11D7-9513-0030655234CE@cwi.nl> On Wednesday, Apr 16, 2003, at 01:05 Europe/Amsterdam, Just van Rossum wrote: > Chris Barker wrote: > >> Just van Rossum wrote: >>>> Turns out it doesn't matter: site.py will remove it if it doesn't >>>> exist. >>> >>> Not anymore in 2.3. >> >> So what does 2.3 do with directories on PYTHONPATH that don't exist? > > Nothing, it leaves them in. The idea is that there may be importer > objects on sys.path_hooks that can handle them (see PEP 302). This may be true for items from PYTHONPATH, but not for site-packages. The code says for sitedir in sitedirs: if os.path.isdir(sitedir): addsitedir(sitedir) -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From berkowit@silcom.com Wed Apr 16 13:18:54 2003 From: berkowit@silcom.com (Paul Berkowitz) Date: Wed, 16 Apr 2003 05:18:54 -0700 Subject: [Pythonmac-SIG] sys.path for MacPython 2.3 - next set of questions Message-ID: On 4/15/03 2:33 PM, "Jack Jansen" wrote: > Paul, > don't worry: this is exactly what we're trying to do, make MacPython 2.3 > so comfortable to both Mac-heads and Unix-heads that there really is no reason > to use anything else. > > The bad news about standard inclusion by Apple, however, is timing. I don't > expect to see MacPython 2.3 as part of 10.3, see my other message of tonight > for why not. So for 2.3 one of my concerns is making sure MacPython 2.3 and > any other Python (either Apple-installed or user-installed) are not going to > bite each other, perhaps even cooperate, and at the very least cause as little > user confusion as possible. Would it eventually be possible - with 2.3 or a future version - to make Mac "additions" to the standard install rather than a whole other installation? Then it might even be possible to provide users with a simple installer of these additions. Do I gather from some of your recent posts that you might be attempting to set up something of this sort? I would appreciate a reference to somewhere that would explain why Mac-only additions are needed or are desirable in Mac OS X. I can understand why you might want to have a later, better version of Python for development than makes it into the last OS release. But what are these Carbon libraries I've seen mention of? Are these ports of components required for MacPython in OS 8/9 that let developers port their classic applications to OS X? Or something else? > > And: definitely keep the comments coming. There's enough unix-expertise and > MacOS9-Python expertise here so that we won't make too many bad mistakes in > that area (cross fingers), but what we're *really* after is the new converts > like yourself. Thank you for your kind welcome. I found my way here initially here because I needed help with Mac-specific PYTHONPATH and PATH on OS 10.2. Most of the discussions here are about matters beyond my comprehension (comp.lang.python seems more up my present alley) although I'll continue to ask a few questions about basic Python language now and again if that's OK. I'm coming from somewhere probably quite different from most others here: somewhere that I think could probably prove quite a fallow "recruiting ground" for Python on the Mac in future if things are made uncomplicated. I'm coming from AppleScript. When I discovered the enormous wealth of Unix capabilities suddenly opened up by OS X, including through 'do shell script' in AppleScript itself, I didn't know where to start - there's just too much. So many different languages. A couple of people advised me to look at Python, and I was hooked. It can do everything, it seems, and then some. But there's an added advantage for AppleScripters - Python's language has a family resemblance. Much of it seems familiar at first sight - lists, dictionaries (records in AppleScript) being mutable, strings immutable, indentation, untyped variables, an expressive non-cryptic vocabulary, and its OOP. Python's OOP is much more thoroughgoing - creating my own classes has been the most foreign aspect for me (although you can create script objects in AppleScript, they're less used and less versatile). AppleScript's syntax is, by design, even more "English-like" - I know the alternative legal versions of expressions bothers some people (but it's really rather trivial) - but again there are similarities when compared with the impenetrable symbolism of Perl. Apple is planning a new version of AppleScript (2.0) to be a more serious programming language. I think that AppleScript and Python complement each other very well, and Python may well get some more "converts" from AS if there's a clear path laid out. I've seen one or two familiar names here already. -- Paul Berkowitz From lanceboyle@myrealbox.com Wed Apr 16 23:54:47 2003 From: lanceboyle@myrealbox.com (Lance Boyle) Date: Wed, 16 Apr 2003 15:54:47 -0700 Subject: [Pythonmac-SIG] gnuplot-py Message-ID: <6C65EB00-705E-11D7-9B63-003065F93FF0@myrealbox.com> How would one get gnuplot-py to work with MacPython (2.2.2)? I can get it to work from "Terminal Python 2.2.2" and "xterm Python 2.2.2" and send the plotting output to either X11 or AquaTerm in both cases but the "import Gnuplot" fails with MacPython. I've changed sys.path to where I think it should see the right place but to no avail. Jerry From wlmyers@mac.com Thu Apr 17 11:38:00 2003 From: wlmyers@mac.com (Willard Myers) Date: Thu, 17 Apr 2003 06:38:00 -0400 Subject: [Pythonmac-SIG] SciPy-0.2.0 Message-ID: Has anyone managed to install this in any python distribution on Mac OS X? I'm stuck at: ImportError: No module named setup_scipy_distutils Bill From wtbridgman@radix.net Thu Apr 17 12:22:31 2003 From: wtbridgman@radix.net (W.T. Bridgman) Date: Thu, 17 Apr 2003 07:22:31 -0400 Subject: [Pythonmac-SIG] Using Project Builder with Python & SWIG? Message-ID: Has anyone on the list used SWIG to build Python wrappers and compile them with Project Builder? I've got command line SWIG 1.3.19 to generate my wrappers for Python 2.2.2 (Unix) but I can't get PB to build a _.so library file that Python will import. (I gave up using MacSWIG - it could never find some of it's own config files). I had this module working under MacOS 8 and CodeWarrior with available documentation. I assume there's some flag I'm missing. I tried -shared in the compiler (and linker) flags with no success. I haven't resorted to compiling from the command line yet, but I'd like to know how to do this with PB. .a libraries are easy but Python won't import them. I've checked several online and hardcopy books and magazine tutorials on PB and haven't found info on this yet. Would a .dyld work in this case? Thanks for your assistance, Tom From Jack.Jansen@oratrix.com Thu Apr 17 20:26:22 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Thu, 17 Apr 2003 21:26:22 +0200 Subject: [Pythonmac-SIG] Using Project Builder with Python & SWIG? In-Reply-To: Message-ID: <78D43C7E-710A-11D7-AE99-000A27B19B96@oratrix.com> On donderdag, apr 17, 2003, at 13:22 Europe/Amsterdam, W.T. Bridgman wrote: > Has anyone on the list used SWIG to build Python wrappers and compile > them with Project Builder? I got it to work with PyOpenGL, but I do know that it was a lot of work. Although I think the main work was finding the exact version of SWIG. Apparently even micro-releases of swig can introduce incompatibilities and the PyOpenGL documentation didn't specify exactly which swig version was needed (this has since been fixed, I think). So if you grab a PyOpenGL distribution you should be able to find out how to call swig on OSX. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From dsposx@mac.com Fri Apr 18 01:15:29 2003 From: dsposx@mac.com (Donovan Preston) Date: Thu, 17 Apr 2003 17:15:29 -0700 Subject: [Pythonmac-SIG] Using Project Builder with Python & SWIG? In-Reply-To: Message-ID: This may be completely unhelpful, but back when I was building some simple extension modules I would use project builder to edit the .c files. I set up project builder to run "python setup.py build" as a build shell step, then set up the executable as "python mypyfile.py". Then, hitting run would build the c extensions, and start the python process. I believe I even got as far as being able to set breakpoints in the .c files for the extension module I was writing, and using the Project Builder debugger. It's been about a year and a half since I did this. I'm sure if I looked hard enough I could dig out some old Project Builder projects off some archives to see how I had things set up. Donovan From berkowit@silcom.com Fri Apr 18 17:55:13 2003 From: berkowit@silcom.com (Paul Berkowitz) Date: Fri, 18 Apr 2003 09:55:13 -0700 Subject: [Pythonmac-SIG] Which documentation? Message-ID: I'm trying to discover which set of Documentation applies to the default Python 2.2 installed by Mac OS 10.2. There are two separate sets of Documentation at python.org for Python 2.2. One was released 21 December 2001, the other on 29 March 2002. When you go to the latter it says it's Python 2.2p1. Is this an updated (corrected?) documentation for the same Python 2.2 release as the other, or is it documentation for a 2.2p1 update of Python itself? And which one have I got? I've asked at comp.lang.python as well, but I'm not sure that anyone there will know which set applies to the Python 2.2 in Mac OS 10.2. Thanks for any clarification which can be provided. -- Paul Berkowitz From deleeuw@stat.ucla.edu Fri Apr 18 23:41:11 2003 From: deleeuw@stat.ucla.edu (Jan de Leeuw) Date: Fri, 18 Apr 2003 15:41:11 -0700 Subject: [Pythonmac-SIG] strange message Message-ID: --Apple-Mail-4--615972319 Content-Transfer-Encoding: 7bit Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed IDLE from CVS does not open properly and says (in the console) confusingly Traceback (most recent call last): File "/Applications/MacPython-2.3/IDLE.app/Contents/Resources/ __argvemulator_idle", line 4, in ? execfile(os.path.join(os.path.split(__file__)[0], "idle")) File "/Applications/MacPython-2.3/IDLE.app/Contents/Resources/idle", line 12, in ? PyShell.main() File "/Applications/MacPython-2.3/IDLE.app/Contents/Resources/idlelib/ PyShell.py", line 756, in main root = Tk(className="Idle") File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/lib- tk/Tkinter.py", line 1572, in __init__ raise RuntimeError, \ RuntimeError: tcl.h version (8.5) doesn't match libtcl.a version (8.5) Traceback (most recent call last): File "/Applications/MacPython-2.3/IDLE.app/Contents/Resources/ __argvemulator_idle", line 4, in ? execfile(os.path.join(os.path.split(__file__)[0], "idle")) File "/Applications/MacPython-2.3/IDLE.app/Contents/Resources/idle", line 12, in ? PyShell.main() File "/Applications/MacPython-2.3/IDLE.app/Contents/Resources/idlelib/ PyShell.py", line 756, in main root = Tk(className="Idle") File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/lib- tk/Tkinter.py", line 1572, in __init__ raise RuntimeError, \ RuntimeError: tcl.h version (8.5) doesn't match libtcl.a version (8.5) === Jan de Leeuw; Professor and Chair, UCLA Department of Statistics; Editor: Journal of Multivariate Analysis, Journal of Statistical Software US mail: 9432 Boelter Hall, Box 951554, Los Angeles, CA 90095-1554 phone (310)-825-9550; fax (310)-206-5658; email: deleeuw@stat.ucla.edu homepage: http://gifi.stat.ucla.edu ------------------------------------------------------------------------ ------------------------- No matter where you go, there you are. --- Buckaroo Banzai http://gifi.stat.ucla.edu/sounds/nomatter.au ------------------------------------------------------------------------ ------------------------- --Apple-Mail-4--615972319 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII IDLE from CVS does not open properly and says (in the console) confusingly Traceback (most recent call last): File "/Applications/MacPython-2.3/IDLE.app/Contents/Resources/__argvemulator_idle", line 4, in ? execfile(os.path.join(os.path.split(__file__)[0], "idle")) File "/Applications/MacPython-2.3/IDLE.app/Contents/Resources/idle", line 12, in ? PyShell.main() File "/Applications/MacPython-2.3/IDLE.app/Contents/Resources/idlelib/PyShell.py", line 756, in main root = Tk(className="Idle") File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/lib-tk/Tkinter.py", line 1572, in __init__ raise RuntimeError, \ RuntimeError: tcl.h version (8.5) doesn't match libtcl.a version (8.5) Traceback (most recent call last): File "/Applications/MacPython-2.3/IDLE.app/Contents/Resources/__argvemulator_idle", line 4, in ? execfile(os.path.join(os.path.split(__file__)[0], "idle")) File "/Applications/MacPython-2.3/IDLE.app/Contents/Resources/idle", line 12, in ? PyShell.main() File "/Applications/MacPython-2.3/IDLE.app/Contents/Resources/idlelib/PyShell.py", line 756, in main root = Tk(className="Idle") File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/lib-tk/Tkinter.py", line 1572, in __init__ raise RuntimeError, \ RuntimeError: tcl.h version (8.5) doesn't match libtcl.a version (8.5) === Jan de Leeuw; Professor and Chair, UCLA Department of Statistics; Editor: Journal of Multivariate Analysis, Journal of Statistical Software US mail: 9432 Boelter Hall, Box 951554, Los Angeles, CA 90095-1554 phone (310)-825-9550; fax (310)-206-5658; email: deleeuw@stat.ucla.edu homepage: http://gifi.stat.ucla.edu ------------------------------------------------------------------------------------------------- No matter where you go, there you are. --- Buckaroo Banzai http://gifi.stat.ucla.edu/sounds/nomatter.au ------------------------------------------------------------------------------------------------- --Apple-Mail-4--615972319-- From wtbridgman@radix.net Sat Apr 19 01:14:56 2003 From: wtbridgman@radix.net (W.T. Bridgman) Date: Fri, 18 Apr 2003 20:14:56 -0400 Subject: [Pythonmac-SIG] Using Project Builder with Python & SWIG? In-Reply-To: Message-ID: While not quite what I was looking for, this idea does have some appeal. While I have no current plans to distribute the code in question, it would make it easier for cross-platform installs and re-installing after a python upgrade. I printed off the distutils docs and will study them. Any pointers you can provide would be appreciated. Thanks, Tom On Thursday, April 17, 2003, at 08:15 PM, Donovan Preston wrote: > This may be completely unhelpful, but back when I was building some > simple extension modules I would use project builder to edit the .c > files. I set up project builder to run "python setup.py build" as a > build shell step, then set up the executable as "python mypyfile.py". > Then, hitting run would build the c extensions, and start the python > process. I believe I even got as far as being able to set breakpoints > in the .c files for the extension module I was writing, and using the > Project Builder debugger. > > It's been about a year and a half since I did this. I'm sure if I > looked hard enough I could dig out some old Project Builder projects > off some archives to see how I had things set up. > > Donovan > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From berkowit@silcom.com Sat Apr 19 18:06:26 2003 From: berkowit@silcom.com (Paul Berkowitz) Date: Sat, 19 Apr 2003 10:06:26 -0700 Subject: [Pythonmac-SIG] Which version of Python 2.2 is in OS 10.2? Message-ID: I did not get an answer at comp.lang.py, so I'm writing again here. Can someone tell me which version of Python 2.2 is in the default Mac OS 10.2 distribution? The complete list of Python Documentation includes two different sets for Python 2.2: one released on 21 December 2001 and the other on 29 March 2002. The Index refers to both simply as "Python 2.2": that can't be right, can it? When you go to the second one (29 March 2002), it actually claims to be "Python 2.2p1" and the browser window title says "Python 2.2, update 1". I cannot find any "What's new in Python 2.2p1" summary anywhere. So far, after several hours of reading all the Built-ins and Modules documentation I haven't come upon a single instance of "New in 2.2p1". 'man python' in Terminal shows a date of 2002-02-05. I guess that points strongly to the earlier 2.2, pre-update, as being the installed version? I can't find any other indicators. If someone can confirm this, or otherwise, I'd very much appreciate it if you would tell me. Thank you. -- Paul Berkowitz From deleeuw@stat.ucla.edu Sat Apr 19 20:25:05 2003 From: deleeuw@stat.ucla.edu (Jan de Leeuw) Date: Sat, 19 Apr 2003 12:25:05 -0700 Subject: [Pythonmac-SIG] more about Tkinter strangeness Message-ID: <9FF34F96-729C-11D7-A76E-000393BB6D36@stat.ucla.edu> --Apple-Mail-2--541338527 Content-Transfer-Encoding: 7bit Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed If I comment out the following part of Tkinter.py # if tcl_version != _tkinter.TCL_VERSION: # raise RuntimeError, \ # "tcl.h version (%s) doesn't match libtcl.a version (%s)" \ # % (_tkinter.TCL_VERSION, tcl_version) then IDLE does run fine. Of course there is not libtcl.a anyway in a framework build on the Mac. Otherwise IDLE exits with the message Traceback (most recent call last): File "/Applications/MacPython-2.3/IDLE.app/Contents/Resources/ __argvemulator_idle", line 4, in ? execfile(os.path.join(os.path.split(__file__)[0], "idle")) File "/Applications/MacPython-2.3/IDLE.app/Contents/Resources/idle", line 12, in ? PyShell.main() File "/Applications/MacPython-2.3/IDLE.app/Contents/Resources/idlelib/ PyShell.py", line 756, in main root = Tk(className="Idle") File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/lib- tk/Tkinter.py", line 1572, in __init__ raise RuntimeError, \ RuntimeError: tcl.h version (8.4) doesn't match libtcl.a version (8.4) Does not matter if I use tcl/tk from CVS (which is 8.5) or tcl/tk from sourceforge, (which is 8.4). === Jan de Leeuw; Professor and Chair, UCLA Department of Statistics; Editor: Journal of Multivariate Analysis, Journal of Statistical Software US mail: 9432 Boelter Hall, Box 951554, Los Angeles, CA 90095-1554 phone (310)-825-9550; fax (310)-206-5658; email: deleeuw@stat.ucla.edu homepage: http://gifi.stat.ucla.edu ------------------------------------------------------------------------ ------------------------- No matter where you go, there you are. --- Buckaroo Banzai http://gifi.stat.ucla.edu/sounds/nomatter.au ------------------------------------------------------------------------ ------------------------- --Apple-Mail-2--541338527 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII If I comment out the following part of Tkinter.py # if tcl_version != _tkinter.TCL_VERSION: # raise RuntimeError, \ # "tcl.h version (%s) doesn't match libtcl.a version (%s)" \ # % (_tkinter.TCL_VERSION, tcl_version) then IDLE does run fine. Of course there is not libtcl.a anyway in a framework build on the Mac. Otherwise IDLE exits with the message Traceback (most recent call last): File "/Applications/MacPython-2.3/IDLE.app/Contents/Resources/__argvemulator_idle", line 4, in ? execfile(os.path.join(os.path.split(__file__)[0], "idle")) File "/Applications/MacPython-2.3/IDLE.app/Contents/Resources/idle", line 12, in ? PyShell.main() File "/Applications/MacPython-2.3/IDLE.app/Contents/Resources/idlelib/PyShell.py", line 756, in main root = Tk(className="Idle") File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/lib-tk/Tkinter.py", line 1572, in __init__ raise RuntimeError, \ RuntimeError: tcl.h version (8.4) doesn't match libtcl.a version (8.4) Does not matter if I use tcl/tk from CVS (which is 8.5) or tcl/tk from sourceforge, (which is 8.4). === Jan de Leeuw; Professor and Chair, UCLA Department of Statistics; Editor: Journal of Multivariate Analysis, Journal of Statistical Software US mail: 9432 Boelter Hall, Box 951554, Los Angeles, CA 90095-1554 phone (310)-825-9550; fax (310)-206-5658; email: deleeuw@stat.ucla.edu homepage: http://gifi.stat.ucla.edu ------------------------------------------------------------------------------------------------- No matter where you go, there you are. --- Buckaroo Banzai http://gifi.stat.ucla.edu/sounds/nomatter.au ------------------------------------------------------------------------------------------------- --Apple-Mail-2--541338527-- From mwh@python.net Sat Apr 19 22:18:06 2003 From: mwh@python.net (Michael Hudson) Date: Sat, 19 Apr 2003 22:18:06 +0100 Subject: [Pythonmac-SIG] Which version of Python 2.2 is in OS 10.2? In-Reply-To: (Paul Berkowitz's message of "Sat, 19 Apr 2003 10:06:26 -0700") References: Message-ID: <2mistap4oh.fsf@starship.python.net> Paul Berkowitz writes: > I did not get an answer at comp.lang.py, so I'm writing again here. Can > someone tell me which version of Python 2.2 is in the default Mac OS 10.2 > distribution? Someone answered. Maybe you can check google. The Apple-bundled Python is "2 point 2 point nothing", aka 2.2. Not 2.2.1 or 2.2.2. > The complete list of Python Documentation includes two different sets for > Python 2.2: one released on 21 December 2001 and the other on 29 March 2002. > The Index refers to both simply as "Python 2.2": that can't be right, can > it? If the answer on c.l.py is to be believed the latter is an update *to the documentation* for 2.2. But the differences in docs between 2.2 amd 2.2.1 will be largely insignificant. Cheers, M. -- Slim Shady is fed up with your shit, and he's going to kill you. -- Eminem, "Public Service Announcement 2000" From Jack.Jansen@oratrix.com Sat Apr 19 23:50:43 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 20 Apr 2003 00:50:43 +0200 Subject: [Pythonmac-SIG] more about Tkinter strangeness In-Reply-To: <9FF34F96-729C-11D7-A76E-000393BB6D36@stat.ucla.edu> Message-ID: <59D638A2-72B9-11D7-9743-000A27B19B96@oratrix.com> Try printing both _tkinter.TCL_VERSION and tcl_version as what they really are, i.e., something like print (_tkinter.TCL_VERSION, tcl_version) My guess is that one is a string and the other a float, or something silly like that. Of course, I have no idea why this should be the case... -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From berkowit@silcom.com Sun Apr 20 01:31:40 2003 From: berkowit@silcom.com (Paul Berkowitz) Date: Sat, 19 Apr 2003 17:31:40 -0700 Subject: [Pythonmac-SIG] Which version of Python 2.2 is in OS 10.2? In-Reply-To: <2mistap4oh.fsf@starship.python.net> Message-ID: On 4/19/03 2:18 PM, "Michael Hudson" wrote: > Paul Berkowitz writes: > >> I did not get an answer at comp.lang.py, so I'm writing again here. Can >> someone tell me which version of Python 2.2 is in the default Mac OS 10.2 >> distribution? > > Someone answered. Maybe you can check google. Hmm. Still doesn't show up. That newsgroup gets so much traffic, I might have to keep digging. But Fred Drake (editor of the docs) wrote me privately now, so I know the answer. (See below.) > > The Apple-bundled Python is "2 point 2 point nothing", aka 2.2. Not > 2.2.1 or 2.2.2. Right. I knew that, thanks. It was the "2.2p1" I didn't know about. > >> The complete list of Python Documentation includes two different sets for >> Python 2.2: one released on 21 December 2001 and the other on 29 March 2002. >> The Index refers to both simply as "Python 2.2": that can't be right, can >> it? > > If the answer on c.l.py is to be believed the latter is an update *to > the documentation* for 2.2. Yes; I wondered about that in my original query. Thank you. That's what Fred confirmed - the 2.2p1 set is a corrected and partly expanded set of docs, with no change to Python 2.2 itself. (It seems to me that the original, faulty set of 2.2 docs should now be withdrawn from the website - I can't quite see what purpose it serves.) > > But the differences in docs between 2.2 amd 2.2.1 will be largely > insignificant. Fred added that the 2.2.2 docs give expanded explanations, and that there were no new features in 2.2.1 and 2.2.2. I gather from this list there there were lots and lots of bug fixes, but those shouldn't affect the docs much. I'm sure that even if there were a few changes, it will say "New in 2.2.2", so I'll use the 2.2.2 set once I finish plowing through the 2.2p1 set. Thank you for responding. -- Paul Berkowitz From altis@semi-retired.com Sun Apr 20 19:39:33 2003 From: altis@semi-retired.com (Kevin Altis) Date: Sun, 20 Apr 2003 11:39:33 -0700 Subject: [Pythonmac-SIG] GUI apps appearing behind other apps on startup Message-ID: I've brought this up before, but I don't remember if there was a solution. I seem to remember Just saying that making a bundle solved the problem, but I can't even find that email. Besides that is only a partial solution since I don't want to have to build bundles while developing/testing an app. Anyway, using the 2.3a2 binary the Robin built and wxPython 2.4.0.7, double-clicking a GUI script (uses PythonLauncher) or starting it with pythonw in the Terminal causes the app to appear behind other windows on the desktop. The more I use Python to create apps on Mac OS X, the more it bothers me. Since I think I finally have control dragging working correctly in the resourceEditor across Mac OS X, Linux, and Windows this is going to become a big deal for anyone making use of PythonCard on Mac OS X. Note that trying a trick in wxPython like calling wx.wxCallAfter(self.frame.Raise) as part of the application initialization doesn't solve the problem. So, would it be possible for the PythonLauncher and/or pythonw to raise the app via a Mac OS X system call? Other ideas? On a related note, I haven't had good luck creating bundles of wxPython scripts and in particular PythonCard scripts, but that is a separate issue that I need some help on so I can get a sample of doing it into the PythonCard distribution. ka --- Kevin Altis altis@semi-retired.com http://altis.pycs.net/ http://www.pythoncard.org/ From Jack.Jansen@oratrix.com Sun Apr 20 22:26:35 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 20 Apr 2003 23:26:35 +0200 Subject: [Pythonmac-SIG] GUI apps appearing behind other apps on startup In-Reply-To: Message-ID: On zondag, apr 20, 2003, at 20:39 Europe/Amsterdam, Kevin Altis wrote: > I've brought this up before, but I don't remember if there was a > solution. I > seem to remember Just saying that making a bundle solved the problem, > but I > can't even find that email. Besides that is only a partial solution > since I > don't want to have to build bundles while developing/testing an app. > > Anyway, using the 2.3a2 binary the Robin built and wxPython 2.4.0.7, > double-clicking a GUI script (uses PythonLauncher) or starting it with > pythonw in the Terminal causes the app to appear behind other windows > on the > desktop. The problem isn't specific to Python: *any* program launched from the Terminal window will start behind the terminal. My guess is that the problem is probably unsolvable[*] for calling pythonw from the Terminal window, but that it may be solvable for PythonLauncher, by switching to Launch Services to start pythonw. As Apple always states that there is no magic in the Finder any more but all the magic is in Launch Services that may do the trick. But the problem then is finding out how to pass all the right options. Feel free to post a bug report, adding working code will speed it up immensely:-) [*] I think there is a solution for pythonw too, by using the undocumented and unsupported CPS calls. I want to stay away from them, however, as they are not part of the official API, and the Tcl/Tk folks were explicitly warned to not use them. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Sun Apr 20 22:30:17 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 20 Apr 2003 23:30:17 +0200 Subject: [Pythonmac-SIG] GUI apps appearing behind other apps on startup In-Reply-To: Message-ID: <4808E1FE-7377-11D7-8370-000A27B19B96@oratrix.com> On zondag, apr 20, 2003, at 20:39 Europe/Amsterdam, Kevin Altis wrote: > Note that trying a trick in wxPython like calling > > wx.wxCallAfter(self.frame.Raise) > > as part of the application initialization doesn't solve the problem. > So, > would it be possible for the PythonLauncher and/or pythonw to raise > the app > via a Mac OS X system call? Other ideas? Sorry, I missed this part. If you don't mind fixing the problem in your script there is a very easy way to do it: import MacOS if not MacOS.WMAvailable(): raise "Cannot reach the window manager" WMAvailable() returns true if you can use the window manager, and as a side effect it raises the application to the foreground. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From andrew.straw@adelaide.edu.au Mon Apr 21 06:34:53 2003 From: andrew.straw@adelaide.edu.au (Andrew Straw) Date: Mon, 21 Apr 2003 15:04:53 +0930 Subject: [Pythonmac-SIG] SciPy-0.2.0 In-Reply-To: <5D20CFF8-72AE-11D7-B6A5-000A959CAD34@mac.com> Message-ID: On Sunday, April 20, 2003, at 07:02 AM, Willard Myers wrote: > On Friday, Apr 18, 2003, at 00:35 America/New_York, Andrew Straw wrote: > >> I've got scipy working just fine on my mac os x box. I'm using >> MacPython 2.3a2 and a recent CVS checkout of scipy. > > Thanks! It helps to know that it is doable. > > If you have a moment, I'd like to know how you dealt with building the > fortran source, and whether or not you found a way to use Apple's BLAS > and LAPACK libraries in the vecLib framework? That's funny -- I asked the same thing on the SciPy list several months ago. It seems like a good idea, but IIRC the scipy folks wrap fortran, and I think the apple stuff is CLAPACK. Still, although I'm not an expert on this stuff and haven't done any benchmarking, I've been using ATLAS, which seems fast. I used fink to install atlas, etc (and even a version of python that I never use), and then I compiled scipy from CVS after creating (from a default copy sitting nearby) scipy_core/scipy_distutils/site.cfg and adding /sw/lib and /sw/include to the [DEFAULT] section. It's worth it. Cheers! Andrew From postmaster@adcomsolutions.com Mon Apr 21 19:44:43 2003 From: postmaster@adcomsolutions.com (postmaster@adcomsolutions.com) Date: Mon, 21 Apr 2003 14:44:43 -0400 Subject: [Pythonmac-SIG] MDaemon Warning - Virus Found Message-ID: The following message had attachment(s) which contained the viruses: >From : carver_alex50@earthlink.net To : pythonmac-sig@python.org Subject : Van Rossum (home page Date : Message-ID: Attachment Virus name Action taken ------------------------------------------------------------------------------ cf207751581.att Exploit.IFrame.FileDownloadRemoved README.scr I-Worm.Klez.h Removed From owen@astro.washington.edu Mon Apr 21 20:10:51 2003 From: owen@astro.washington.edu (Russell E Owen) Date: Mon, 21 Apr 2003 12:10:51 -0700 Subject: [Pythonmac-SIG] help build unix python on Mac Message-ID: I've already installed a framework build of Python 2.2.2 (with Aqua Tk 8.4.1) from source. I would also like a non-framework build that uses unix X style Tk windows (so I can see how my application will look to unix users). The problem I have is I keep getting a python that uses the Aqua (framework) Tk instead of the unix X Tk that I also have installed. Any hints on how to do this? Details on what I tried are appended. I suppose I can just use fink, but was hoping to just do everything from source. -- Russell Details: - I first installed the framework stuff from source (tcl 8.4.1, tk 8.4.1 and Python 2.2.2). I did this many months ago and have been happily using it ever since. So...the next step was to get the non-framework unix X stuff installed: - installed Apple's X11 application and X11 SDK using Apple's two package installers - tried to clear out as much of the old stuff as possible, having first plowed ahead w/out and run into the problem of Python seeing only the framework Tk: - went into /usr/local - deleted all tcl and Tk and python stuff (except pythonw) in ./bin, ./includes and ./lib. I then built tcl and Tk from their unix directories. This worked with a few warnings. One oddity: there was a /usr/local/bin/wish8.4 but no /usr/local/bin/wish. If I typed "wish" at the terminal I got the Aqua (framework) wish. So I I made /usr/local/wish a symbolic link, closed the terminal window and opened a new one (as one seems to have to do after messing with /usr/local/bin). unix X11-baseed Tk seems to work. Typing % wish at a Terminal brings up the X11 wish. I can add widgets and use them. That's all the testing I've done. I then rebuilt python using: % make clean % ./configure % make Unfortunately, it is linking against the framework build of Tcl/Tk. I get warnings like: /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:140: warning: function declaration isn't a prototype and if I finish with sudo make install I get the usual framework Tk stuff. I've tried about 4 variations on of this sequence with no luck. I really don't want to have to clear *everything* (including the framework stuff) out and risk breaking a working framework build. Any suggestions? From Jack.Jansen@oratrix.com Mon Apr 21 21:47:20 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Mon, 21 Apr 2003 22:47:20 +0200 Subject: [Pythonmac-SIG] help build unix python on Mac In-Reply-To: Message-ID: <7206E4CB-743A-11D7-868F-000A27B19B96@oratrix.com> On maandag, apr 21, 2003, at 21:10 Europe/Amsterdam, Russell E Owen wrote: > I've already installed a framework build of Python 2.2.2 (with Aqua Tk > 8.4.1) from source. I would also like a non-framework build that uses > unix X style Tk windows (so I can see how my application will look to > unix users). > > The problem I have is I keep getting a python that uses the Aqua > (framework) Tk instead of the unix X Tk that I also have installed. > > Any hints on how to do this? Details on what I tried are appended. Look in setup.py in the toplevel Python source directory. It had a large amount of code that specifically tries to locate your Tcl and Tk. There's a special section that is executed first that looks for AquaTk. If you disable that (*and* if you have installed X11 and a normal X11 Tcl/Tk too, in the usual place) the normal unix code should kick in and you should get an _tkinter that uses that. I haven't tried this, though, so please let us know whether it works:-) -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Mon Apr 21 22:58:13 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Mon, 21 Apr 2003 23:58:13 +0200 Subject: [Pythonmac-SIG] Organizing the MacPython website Message-ID: <597D684A-7444-11D7-868F-000A27B19B96@oratrix.com> Folks, I'm at a dead end as far as organizing the new MacPython website is concerned, and as I want to have this finished soon I need a couple of kicks in the right direction. In order of importance, I don't know what has to be on the site, I don't know how to organize it, and I don't know what it should look like. Well, I have some ideas, but not enough. Shoot away. First on the content. Here's what I think should be there (note that these probably don't all need to be on a page of their own): - A quick (2 paragraph?) introduction to Python, pointing to www.python.org for more detail. - An introduction to MacPython-OSX, explaining what extra goodies there are when compared to Python on other platforms. - An explanation of the various Pythons for MacOSX (MacPython-OSX, /usr/bin/python, other unix distributions including 2.2.2 and fink, maybe more). - A documentation section (mainly pointing to www.python.org) - A community section (listing this mailing list, comp.lang.python{.help}, and again pointing to www.python.org). - Developers info (listing alfa and beta releases, cvs access, and again www.python.org). - A download page. - An FAQ. - A page with older MacPythons (MacPython-OS9 and older), plus platforms they run on. - Information on Jython? - Comparison of /usr/bin/python, MacPython-OSX, fink-python, Jython? - Sections on special topics. We definitely need a section on GUI programming and applescripting, possibly later also on scientific computing and more (although for these we could again refer to common pages on www.python.org or so). Anything I miss? As to organization things are even muddier. The standard commercial breakdown of Products/Download/Support/Company doesn't work, I think, and I don't see a a simple modification that does. I also don't like the organization of 99% of the open source sites I visited, as they all seem to think that you come to the site already knowing what you need. And as we can see from the questions here a lot of people don't know what they need, possibly not even what they already have (hence I want the info on Apple's Python too). I've done mental experiments with the www.python.org organization (logical organization, that is, as presented by the layout of the homepage), with sections at the top and subsections at the left side, where the sebsections of the home page are the "quick navigation"), but I can't get it to work either. Design is probably the least important, but here I really have no clue. On the one hand sticking to www.python.org style would have the benefit of being recognizable to old Python hands, but when compared to other Macintosh pages it looks like something from the dark ages. The good news here, though, is that other people are thinking about www.python.org, so that may lead to something. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From kevino@tulane.edu Tue Apr 22 01:22:48 2003 From: kevino@tulane.edu (Kevin Ollivier) Date: Mon, 21 Apr 2003 17:22:48 -0700 Subject: [Pythonmac-SIG] Organizing the MacPython website References: <597D684A-7444-11D7-868F-000A27B19B96@oratrix.com> Message-ID: <2f2201c30865$4f6b0a40$6701a8c0@dellPC> ----- Original Message ----- From: "Jack Jansen" To: Sent: Monday, April 21, 2003 2:58 PM Subject: [Pythonmac-SIG] Organizing the MacPython website > Folks, > I'm at a dead end as far as organizing the new MacPython website is > concerned, and as I want to have this finished soon I need a couple of > kicks in the right direction. I'll be glad to supply a couple kicks, although I'm not sure if they will help or hurt. ;-) Let me also make a disclaimer that most of these ideas are off the top of my head, and should be taken with a grain of salt. ^_- > In order of importance, I don't know what has to be on the site, I > don't know how to organize it, and I don't know what it should look > like. Well, I have some ideas, but not enough. Shoot away. > > First on the content. Here's what I think should be there (note that > these probably don't all need to be on a page of their own): > - A quick (2 paragraph?) introduction to Python, pointing to > www.python.org for more detail. I found this blurb on the Python.org site that may be a good fit: http://www.python.org/doc/Summary.html However, I think the definition of the word "python" should be removed and that last paragraph should be removed or shortened. > - An introduction to MacPython-OSX, explaining what extra goodies there > are when compared to Python on other platforms. > - An explanation of the various Pythons for MacOSX (MacPython-OSX, > /usr/bin/python, other unix distributions including 2.2.2 and fink, > maybe more). > - A documentation section (mainly pointing to www.python.org) > - A community section (listing this mailing list, > comp.lang.python{.help}, and again pointing to www.python.org). > - Developers info (listing alfa and beta releases, cvs access, and > again www.python.org). > - A download page. > - An FAQ. > - A page with older MacPythons (MacPython-OS9 and older), plus > platforms they run on. > - Information on Jython? > - Comparison of /usr/bin/python, MacPython-OSX, fink-python, Jython? > - Sections on special topics. We definitely need a section on GUI > programming and applescripting, possibly later also on scientific > computing and more (although for these we could again refer to common > pages on www.python.org or so). > > Anything I miss? > > As to organization things are even muddier. The standard commercial > breakdown of Products/Download/Support/Company doesn't work, I think, > and I don't see a a simple modification that does. I also don't like > the organization of 99% of the open source sites I visited, as they all > seem to think that you come to the site already knowing what you need. > And as we can see from the questions here a lot of people don't know > what they need, possibly not even what they already have (hence I want > the info on Apple's Python too). For organization, here's what I'm thinking: - Home - Intro paragraph (link to Python.org) - New to MacPython? (a sort of "tour" of links with getting started info, advice for *nix/Windows switchers, etc.) - News - Download - Latest MacPython - Link to Python.org for source version - Docs/Reference - Mac modules (IMO, it should be a separate link even if it goes to Python.org) - MacPython FAQ - Python.org link - Developer Tools - PythonIDE - Python Package Manager - PythonLauncher - Mac-specific Guides/HOWTOs/Tutorials - embedding in Mac applications - MacPython and AppleScript - Controlling Mac apps - GUI scripting (and bundle building!) - Python on OS X - compiling/installing *nix modules - different Python flavors on OS X - command-line tools - Framework vs. command line - Support - Mailing Lists - MacPython FAQ - Link to Python.org docs/help page - Pointers to relevant pages/FAQ on the site (i.e. different Python versions, etc.) - Developers - CVS - Developer docs (?) - bug/patch submission rules - Python.org link > I've done mental experiments with the www.python.org organization > (logical organization, that is, as presented by the layout of the > homepage), with sections at the top and subsections at the left side, > where the sebsections of the home page are the "quick navigation"), but > I can't get it to work either. > > Design is probably the least important, but here I really have no clue. > On the one hand sticking to www.python.org style would have the benefit > of being recognizable to old Python hands, but when compared to other > Macintosh pages it looks like something from the dark ages. The good > news here, though, is that other people are thinking about > www.python.org, so that may lead to something. Just off the top of my head, I think maybe a layout like CrazyAppleRumors may work for this site. The look and feel should be different, but I think the basic layout of a big banner with links going down the side is a good fit. It looks simple and clean, not crowded or intimidating, is similar to Python.org's look and feel, and looks "Mac-like" to me. http://www.crazyapplerumors.com/ Well, hope this was of some help! Thanks, Kevin From altis@semi-retired.com Tue Apr 22 01:31:48 2003 From: altis@semi-retired.com (Kevin Altis) Date: Mon, 21 Apr 2003 17:31:48 -0700 Subject: FW: [Pythonmac-SIG] GUI apps appearing behind other apps on startup Message-ID: -----Original Message----- From: Jack Jansen [mailto:Jack.Jansen@oratrix.com] Sent: Monday, April 21, 2003 3:31 AM To: Kevin Altis Cc: Robin Dunn Subject: Re: [Pythonmac-SIG] GUI apps appearing behind other apps on startup On maandag, apr 21, 2003, at 01:10 Europe/Amsterdam, Kevin Altis wrote: > Hi Jack, > thanks for the solution. Unfortunately, there is no WMAvailable in > MacOS, at > least in the MacOS module I have with 2.3a2. I did find the MacOS.so in > python2.3:lib-dynload but other than importing it and inspecting the > module > there isn't much I can do with it. I did grep for WMAvailable in the > Python > 2.3 dir and sub-dirs but didn't find anything either. Sorry, you're right, I added it after 2.3a2. It'll be there in 2.3b1. > So, I decided to take this offlist so we could find the solution, > which may > only be in cvs right now, and then I can post a summary. Assuming > WMAvailable() will be in MacOS then your code can just be added at the > end > of the wxPython app initialization: > > if wx.wxPlatform == "__WXMAC__": > import MacOS > try: > # in case WMAvailable doesn't exist > # use a try/except block > MacOS.WMAvailable() > except: > # not much we can tell the user that would be useful > pass Note that WMAvailable() is primarily meant as a safeguard against trying to do windowing when you don't have access to the window manager (on OSX-server, when not logged in). So the call is best done something like try: if not MacOS.WMAvailable(): print """This program needs access to the screen. Please run with 'pythonw', not 'python', and only when you are logged in on the main display of your mac""" sys.exit(1) except: pass -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From eric.nieuwland@xs4all.nl Tue Apr 22 10:47:45 2003 From: eric.nieuwland@xs4all.nl (Eric Nieuwland) Date: Tue, 22 Apr 2003 11:47:45 +0200 Subject: [Pythonmac-SIG] What should be on sys.path for MacPython 2.3 Message-ID: <77F6A78F-74A7-11D7-9479-000393894CEA@xs4all.nl> I would like to see a repeated structure at each of ~/Library/Python, /Library/Python, and possibly /Network/Library/Python. That way it would be easy to try things locally (or personally) first and then promote then to a higher level. Giving the order User > Machine > Network. This probably means that each of these directories would classify as a possible root to all of the directories in sys.path. From Jack.Jansen@cwi.nl Tue Apr 22 13:32:58 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue, 22 Apr 2003 14:32:58 +0200 Subject: [Pythonmac-SIG] What should be on sys.path for MacPython 2.3 In-Reply-To: <77F6A78F-74A7-11D7-9479-000393894CEA@xs4all.nl> Message-ID: <8CEE4FC6-74BE-11D7-91E1-0030655234CE@cwi.nl> On Tuesday, Apr 22, 2003, at 11:47 Europe/Amsterdam, Eric Nieuwland wrote: > I would like to see a repeated structure at each of ~/Library/Python, > /Library/Python, and possibly /Network/Library/Python. That way it > would be easy to try things locally (or personally) first and then > promote then to a higher level. Giving the order User > Machine > > Network. This has two problems: - There is a lot of code in the Python core that wouldn't understand it, and teaching it about this structure would be a major undertaking. For example, distutils expects there's a single Python tree, it won't be able to pick up Include files or the Makefile from different locations. - The order you suggest (user->machine->network) goes against the Python dictum of "add functionality, but don't replace existing functionality", which is clear from, for instance, the place where site-packages is on sys.path. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From owen@astro.washington.edu Tue Apr 22 17:36:16 2003 From: owen@astro.washington.edu (Russell E Owen) Date: Tue, 22 Apr 2003 09:36:16 -0700 Subject: [Pythonmac-SIG] help build unix python on Mac In-Reply-To: <7206E4CB-743A-11D7-868F-000A27B19B96@oratrix.com> References: <7206E4CB-743A-11D7-868F-000A27B19B96@oratrix.com> Message-ID: At 10:47 PM +0200 4/21/03, Jack Jansen wrote: >On maandag, apr 21, 2003, at 21:10 Europe/Amsterdam, Russell E Owen wrote: > >>I've already installed a framework build of Python 2.2.2 (with Aqua >>Tk 8.4.1) from source. I would also like a non-framework build that >>uses unix X style Tk windows (so I can see how my application will >>look to unix users)....... > >Look in setup.py in the toplevel Python source directory. It had a >large amount of code that specifically tries to locate your Tcl and >Tk. There's a special section that is executed first that looks for >AquaTk. If you disable that (*and* if you have installed X11 and a >normal X11 Tcl/Tk too, in the usual place) the normal unix code >should kick in and you should get an _tkinter that uses that. > >I haven't tried this, though, so please let us know whether it works:-) It worked! It was easy to find the subroutine and easy to tell that it returned 0 if it could not find Aqua Tk. So I just made it return 0 right away, redid the build from scratch and got a working X-based Python/Tkinter. Of course the framework and unix-X Pythons do *not* share add-on packages. Fortunately I only use a few. Also fortunately Python cleverly installs packages in the version of python you use to run setup.py; otherwise it would be a nightmare trying to maintain multiple versions of Python on a computer. Thank you very much! -- Russell From Chris.Barker@noaa.gov Tue Apr 22 19:43:57 2003 From: Chris.Barker@noaa.gov (Chris Barker) Date: Tue, 22 Apr 2003 11:43:57 -0700 Subject: [Pythonmac-SIG] Organizing the MacPython website References: <597D684A-7444-11D7-868F-000A27B19B96@oratrix.com> <2f2201c30865$4f6b0a40$6701a8c0@dellPC> Message-ID: <3EA58D6D.FFA6493@noaa.gov> Kevin Ollivier wrote: > - New to MacPython? (a sort of "tour" of links with getting started info, > advice for *nix/Windows switchers, etc.) This is a great idea, and I think it should be broken down to a few separate pages: -New to Python (and maybe break this down into new to programming / just new to Python) -Familiar with Python on Windows -Familiar with Python on *nix We might also want to have separate pages for: - command-line/ web/ cgi, etc (Unixy stuff) - GUI programming (mac-y stuff) -Chris -- -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From skip@pobox.com Tue Apr 22 20:03:06 2003 From: skip@pobox.com (Skip Montanaro) Date: Tue, 22 Apr 2003 14:03:06 -0500 Subject: [Pythonmac-SIG] Organizing the MacPython website In-Reply-To: <3EA58D6D.FFA6493@noaa.gov> References: <597D684A-7444-11D7-868F-000A27B19B96@oratrix.com> <2f2201c30865$4f6b0a40$6701a8c0@dellPC> <3EA58D6D.FFA6493@noaa.gov> Message-ID: <16037.37354.148099.609256@montanaro.dyndns.org> Just noticed this thread. The marketing-python@wingide.com and pydotorg-redesign@python.org mailing lists are discussing topics which might be germane to a MacPython website (and vice versa). Might be worth making a connection. Skip From lep@aber.ac.uk Tue Apr 22 20:43:51 2003 From: lep@aber.ac.uk (Leighton Pritchard) Date: Tue, 22 Apr 2003 20:43:51 +0100 Subject: [Pythonmac-SIG] SciPy-0.2.0 In-Reply-To: References: <5D20CFF8-72AE-11D7-B6A5-000A959CAD34@mac.com> Message-ID: <5.1.0.14.0.20030422203938.00a87bb8@pophost.aber.ac.uk> At 15:04 21/04/2003 +0930, you wrote: >On Sunday, April 20, 2003, at 07:02 AM, Willard Myers wrote: >>On Friday, Apr 18, 2003, at 00:35 America/New_York, Andrew Straw wrote: >>>I've got scipy working just fine on my mac os x box. I'm using >>>MacPython 2.3a2 and a recent CVS checkout of scipy. >> >>Thanks! It helps to know that it is doable. >> >>If you have a moment, I'd like to know how you dealt with building the >>fortran source, and whether or not you found a way to use Apple's BLAS >>and LAPACK libraries in the vecLib framework? > >That's funny -- I asked the same thing on the SciPy list several months >ago. It seems like a good idea, but IIRC the scipy folks wrap fortran, >and I think the apple stuff is CLAPACK. Still, although I'm not an expert >on this stuff and haven't done any benchmarking, I've been using ATLAS, >which seems fast. I used fink to install atlas, etc (and even a version >of python that I never use), and then I compiled scipy from CVS after >creating (from a default copy sitting nearby) >scipy_core/scipy_distutils/site.cfg and adding /sw/lib and /sw/include to >the [DEFAULT] section. > >It's worth it. Hi there, I'm having real difficulties getting SciPy going on OS X 10.2. I've tried compiling from two different source downloads and the most recent CVS checkout. I have ATLAS, FFTW from Fink, and wxPython from a source build. I for one would be very grateful if you could give a walkthrough of what you did to get SciPy up-and-running on your machine. All the best, Dr Leighton Pritchard AMRSC T44, Cledwyn Building, Institute of Biological Sciences University of Wales, Aberystwyth, UK, SY23 3DD lep@aber.ac.uk (01970) 622353 PGP key 47B4A485: http://www.keyserver.net http://pgp.mit.edu/ From Jack.Jansen@oratrix.com Tue Apr 22 22:34:06 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Tue, 22 Apr 2003 23:34:06 +0200 Subject: [Pythonmac-SIG] Organizing the MacPython website In-Reply-To: <16037.37354.148099.609256@montanaro.dyndns.org> Message-ID: <25569DBC-750A-11D7-A49D-000A27B19B96@oratrix.com> On dinsdag, apr 22, 2003, at 21:03 Europe/Amsterdam, Skip Montanaro wrote: > Just noticed this thread. The marketing-python@wingide.com and > pydotorg-redesign@python.org mailing lists are discussing topics which > might > be germane to a MacPython website (and vice versa). Might be worth > making a > connection. I'm on those lists, so I'm following that. I hope that the result of those threads will be that there's less that needs to be addressed on the MacPython pages. But the problem remains that MacPython is, to a lot of end users, a completely different beast than the average unix Python. And I specifically want to cater for that crowd: people with no unix background, no intention to learn that (yet:-). If we want to convert people from AppleScript or RealBasic we shouldn't first let them take the hurdle of learning Unix. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From lanceboyle@myrealbox.com Thu Apr 24 00:12:02 2003 From: lanceboyle@myrealbox.com (Lance Boyle) Date: Wed, 23 Apr 2003 16:12:02 -0700 Subject: [Pythonmac-SIG] SciPy-0.2.0 In-Reply-To: <5.1.0.14.0.20030422203938.00a87bb8@pophost.aber.ac.uk> Message-ID: I would also be most grateful. Jerry On Tuesday, Apr 22, 2003, at 12:43 America/Phoenix, Leighton Pritchard wrote: > At 15:04 21/04/2003 +0930, you wrote: >> On Sunday, April 20, 2003, at 07:02 AM, Willard Myers wrote: >>> On Friday, Apr 18, 2003, at 00:35 America/New_York, Andrew Straw >>> wrote: >>>> I've got scipy working just fine on my mac os x box. I'm using >>>> MacPython 2.3a2 and a recent CVS checkout of scipy. >>> >>> Thanks! It helps to know that it is doable. >>> >>> If you have a moment, I'd like to know how you dealt with building >>> the fortran source, and whether or not you found a way to use >>> Apple's BLAS and LAPACK libraries in the vecLib framework? >> >> That's funny -- I asked the same thing on the SciPy list several >> months ago. It seems like a good idea, but IIRC the scipy folks wrap >> fortran, and I think the apple stuff is CLAPACK. Still, although I'm >> not an expert on this stuff and haven't done any benchmarking, I've >> been using ATLAS, which seems fast. I used fink to install atlas, >> etc (and even a version of python that I never use), and then I >> compiled scipy from CVS after creating (from a default copy sitting >> nearby) scipy_core/scipy_distutils/site.cfg and adding /sw/lib and >> /sw/include to the [DEFAULT] section. >> >> It's worth it. > > Hi there, > > I'm having real difficulties getting SciPy going on OS X 10.2. I've > tried compiling from two different source downloads and the most > recent CVS checkout. I have ATLAS, FFTW from Fink, and wxPython from a > source build. > > I for one would be very grateful if you could give a walkthrough of > what you did to get SciPy up-and-running on your machine. > > All the best, > > > Dr Leighton Pritchard AMRSC From jerry@bauck.net Sat Apr 26 05:23:05 2003 From: jerry@bauck.net (Jerry Bauck) Date: Fri, 25 Apr 2003 21:23:05 -0700 Subject: [Pythonmac-SIG] (no subject) Message-ID: From e-mmunity@electric.net Mon Apr 28 20:40:27 2003 From: e-mmunity@electric.net (e-mmunity@electric.net) Date: Mon, Apr 28 2003 12:40:27 -0700 Subject: [Pythonmac-SIG] Receiver Virus Alert Message-ID: This is the E-mmunity virus scanning service at the Electric Mail Company (www.electricmail.com). An email virus was found. Please see details of the virus below: Date: Mon Apr 28 12:40:27 2003 Recipient: pythonmac-sig@python.org Sender: turtle1@eastontelecom.com Message id: 19AEU7-000Gg4-0W{MM-19AEUF-000GiM-00000L-000} Subject: And installation. If you run into trouble, see Virus name: W32.Klez.H@mm Attachment: http.exe Status: Attachment(s) deleted Notified: recipient, sender Thank you for using our services --- The Electric Mail Company www.electricmail.com 604-482-1111 From Jack.Jansen@oratrix.com Tue Apr 29 13:50:56 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Tue, 29 Apr 2003 14:50:56 +0200 Subject: [Pythonmac-SIG] For your eyes only - MacPython-OSX binary distribution Message-ID: <385430D4-7A41-11D7-BBC7-000A27B19B96@oratrix.com> Folks, a MacPython-OSX 2.3b1 binary distribution is available at . This is the first time I've tried to build such an installer, the tools I used are based on the work from Robin Dunn and the wxPython folks. Please give it a try and let me know whether it works, so I can announce it more widely later. This will take a while, though, probably a week or so, because I first want to update the packages that can be installed with Package Manager. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From mwh@python.net Tue Apr 29 14:13:27 2003 From: mwh@python.net (Michael Hudson) Date: Tue, 29 Apr 2003 14:13:27 +0100 Subject: [Pythonmac-SIG] For your eyes only - MacPython-OSX binary distribution In-Reply-To: <385430D4-7A41-11D7-BBC7-000A27B19B96@oratrix.com> (Jack Jansen's message of "Tue, 29 Apr 2003 14:50:56 +0200") References: <385430D4-7A41-11D7-BBC7-000A27B19B96@oratrix.com> Message-ID: <2m65ox4fbc.fsf@starship.python.net> Jack Jansen writes: > Folks, > a MacPython-OSX 2.3b1 binary distribution is available at > . > > This is the first time I've tried to build such an installer, the > tools I used are based on the work from Robin Dunn and the wxPython > folks. Please give it a try and let me know whether it works, so I can > announce it more widely later. This will take a while, though, > probably a week or so, because I first want to update the packages > that can be installed with Package Manager. Before I try this: I have Python installed from CVS as a framework. Do I need to move this out of the way/delete this before installing the above package? Same goes for PyObjC when 0.9 appears... Cheers, M. wishing for the day Python comes via system update -- NUTRIMAT: That drink was individually tailored to meet your personal requirements for nutrition and pleasure. ARTHUR: Ah. So I'm a masochist on a diet am I? -- The Hitch-Hikers Guide to the Galaxy, Episode 9 From lep@aber.ac.uk Tue Apr 29 14:19:37 2003 From: lep@aber.ac.uk (Leighton Pritchard) Date: Tue, 29 Apr 2003 14:19:37 +0100 Subject: [Pythonmac-SIG] For your eyes only - MacPython-OSX binary distribution In-Reply-To: <2m65ox4fbc.fsf@starship.python.net> References: <385430D4-7A41-11D7-BBC7-000A27B19B96@oratrix.com> <385430D4-7A41-11D7-BBC7-000A27B19B96@oratrix.com> Message-ID: <5.1.0.14.0.20030429141742.03c510f0@pophost.aber.ac.uk> At 14:13 29/04/2003 +0100, you wrote: >Jack Jansen writes: > > > Folks, > > a MacPython-OSX 2.3b1 binary distribution is available at > > . > > > > [...] Please give it a try and let me know whether it works, so I can > > announce it more widely later. >Before I try this: I have Python installed from CVS as a framework. >Do I need to move this out of the way/delete this before installing >the above package? I've just installed it over my CVS framework install (having removed nothing first), and all my site-packages are equally accessible. I don't appear to have lost any functionality, yet (IDLE never worked). >Same goes for PyObjC when 0.9 appears... I can't speak for that, however. Dr Leighton Pritchard AMRSC T44, Cledwyn Building, Institute of Biological Sciences University of Wales, Aberystwyth, UK, SY23 3DD lep@aber.ac.uk (01970) 622353 PGP key 47B4A485: http://www.keyserver.net http://pgp.mit.edu/ From Jack.Jansen@oratrix.com Tue Apr 29 15:04:08 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Tue, 29 Apr 2003 16:04:08 +0200 Subject: [Pythonmac-SIG] For your eyes only - MacPython-OSX binary distribution In-Reply-To: <2m65ox4fbc.fsf@starship.python.net> Message-ID: <72482CCE-7A4B-11D7-BBC7-000A27B19B96@oratrix.com> On dinsdag, apr 29, 2003, at 15:13 Europe/Amsterdam, Michael Hudson wrote: > Before I try this: I have Python installed from CVS as a framework. > Do I need to move this out of the way/delete this before installing > the above package? You don't have to, but you would help me if you did (because it'll be more like the experience new users have). If, after testing, you want to go back to your own installation you can simply remove /Library/Frameworks/Python.framework and /Applications/MacPython-2.3 and redo your "make frameworkinstall". -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Tue Apr 29 15:36:43 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Tue, 29 Apr 2003 16:36:43 +0200 Subject: [Pythonmac-SIG] For your eyes only - MacPython-OS9 2.3b1 Message-ID: And a MacPython-OS9 2.3b1 installer is also available. Again: please test it and send reports here, I will announce it wider after I've seen a couple of positive reports. Oh yes: please also mention your OS version (so that I don't announce it before I've had successes from at least OSX and OS9). Download from . An active installer and BinHex versions are also available, source will come shortly. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From tjk@ams.org Tue Apr 29 15:44:06 2003 From: tjk@ams.org (Tom Kacvinsky) Date: Tue, 29 Apr 2003 10:44:06 -0400 Subject: [Pythonmac-SIG] For your eyes only - MacPython-OS9 2.3b1 In-Reply-To: References: Message-ID: <864679024.1051613046@tjk.ams.org> I had a successful install of the OSX version (on 10.2.5). The installer worked like a charm. Nicely done. :-) Tom On 2003/04/29 16:36 +0200 Jack Jansen wrote: > And a MacPython-OS9 2.3b1 installer is also available. Again: please test it > and send reports here, I will announce it wider after I've seen a couple of > positive reports. Oh yes: please also mention your OS version (so that I don't > announce it before I've had successes from at least OSX and OS9). > > Download from . > An active installer and BinHex versions are also available, source will come > shortly. > From daniel_t@earthlink.net Tue Apr 29 18:11:05 2003 From: daniel_t@earthlink.net (Daniel) Date: Tue, 29 Apr 2003 13:11:05 -0400 Subject: [Pythonmac-SIG] For your eyes only - MacPython-OSX binary distribution In-Reply-To: <385430D4-7A41-11D7-BBC7-000A27B19B96@oratrix.com> Message-ID: <8FE78A15-7A65-11D7-922E-003065DC01F8@earthlink.net> --Apple-Mail-2-314621534 Content-Transfer-Encoding: 7bit Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed The PythonIDE fails for me. Here is the traceback from the console: Traceback (most recent call last): File "/Applications/MacPython-2.3/PythonIDE.app/Contents/Resources/ PythonIDE.py", line 51, in ? import PythonIDEMain File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/ PythonIDEMain.py", line 468, in ? PythonIDE() File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/ PythonIDEMain.py", line 36, in __init__ Wapplication.Application.__init__(self, 'Pide') File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/ Wapplication.py", line 28, in __init__ FrameWork.Application.__init__(self) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/plat- mac/FrameWork.py", line 115, in __init__ self.makemenubar() File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/ Wapplication.py", line 269, in makemenubar self.makeusermenus() File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/ PythonIDEMain.py", line 145, in makeusermenus os.mkdir(path) OSError: [Errno 13] Permission denied: '/Scripts' Note, I'm running a multiuser system. Apparently, the IDE is trying to access/create a directory at the root level which isn't allowed by a non-admin user. Possibly this directory should be created by the installer? On Tuesday, April 29, 2003, at 08:50 AM, Jack Jansen wrote: > Folks, > a MacPython-OSX 2.3b1 binary distribution is available at > . > > This is the first time I've tried to build such an installer, the > tools I used are based on the work from Robin Dunn and the wxPython > folks. Please give it a try and let me know whether it works, so I can > announce it more widely later. This will take a while, though, > probably a week or so, because I first want to update the packages > that can be installed with Package Manager. > -- > - Jack Jansen > http://www.cwi.nl/~jack - > - If I can't dance I don't want to be part of your revolution -- Emma > Goldman - > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > --Apple-Mail-2-314621534 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII The PythonIDE fails for me. Here is the traceback from the console: Traceback (most recent call last): File "/Applications/MacPython-2.3/PythonIDE.app/Contents/Resources/PythonIDE.py", line 51, in ? import PythonIDEMain File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/PythonIDEMain.py", line 468, in ? PythonIDE() File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/PythonIDEMain.py", line 36, in __init__ Wapplication.Application.__init__(self, 'Pide') File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/Wapplication.py", line 28, in __init__ FrameWork.Application.__init__(self) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/plat-mac/FrameWork.py", line 115, in __init__ self.makemenubar() File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/Wapplication.py", line 269, in makemenubar self.makeusermenus() File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/PythonIDEMain.py", line 145, in makeusermenus os.mkdir(path) OSError: [Errno 13] Permission denied: '/Scripts' Note, I'm running a multiuser system. Apparently, the IDE is trying to access/create a directory at the root level which isn't allowed by a non-admin user. Possibly this directory should be created by the installer? On Tuesday, April 29, 2003, at 08:50 AM, Jack Jansen wrote: Folks, a MacPython-OSX 2.3b1 binary distribution is available at <. This is the first time I've tried to build such an installer, the tools I used are based on the work from Robin Dunn and the wxPython folks. Please give it a try and let me know whether it works, so I can announce it more widely later. This will take a while, though, probably a week or so, because I first want to update the packages that can be installed with Package Manager. -- - Jack Jansen < http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig --Apple-Mail-2-314621534-- From owen@astro.washington.edu Tue Apr 29 18:19:59 2003 From: owen@astro.washington.edu (Russell E Owen) Date: Tue, 29 Apr 2003 10:19:59 -0700 Subject: [Pythonmac-SIG] For your eyes only - MacPython-OSX binary distribution Message-ID: I just tried the binary installer and it ran fine. I really liked the nice clear simple ReadMe file and the IDE help as well. The one problem I have is that it didn't install Tkinter. I thought that *might* be because my most recent Tcl/Tk installation was an X11 binary (though I have both that and a framework build installed), but I ran the new Aqua Tk 8.4.2 binary installer and reinstalled MacPython 2.3b1-1 and still...no Tkinter. So I'm about to try building Python 2.3b1 from source. -- Russell From larry.bugbee@boeing.com Tue Apr 29 18:51:51 2003 From: larry.bugbee@boeing.com (Bugbee, Larry) Date: Tue, 29 Apr 2003 10:51:51 -0700 Subject: [Pythonmac-SIG] For your eyes only - MacPython-OSX binary distribution Message-ID: <8CFC81BC2CC2A74F88BAB7180F00B779E067F9@XCH-NW-29.nw.nos.boeing.com> So I'm about to try building Python 2.3b1 from source. -- Russell If you build from source you may want to make one tempory change in = Tkinter.py, line 1572. ....str(tcl_version) = http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D729317&group= _id=3D5470&atid=3D105470 Larry From goodger@python.org Tue Apr 29 20:33:38 2003 From: goodger@python.org (David Goodger) Date: Tue, 29 Apr 2003 15:33:38 -0400 Subject: [Pythonmac-SIG] Boa Constructor on Mac OS X? Message-ID: <3EAED392.90405@python.org> Has anyone been able to run Boa Constructor on Mac OS X? I hacked a copy of the wxPython RunDemo.app to run Boa.pyw, but Boa crashes after a time with a Bus Error, and some of the interface elements are messed up (input fields on top of buttons, etc.). Any tips or links would be appreciated. OS X 10.2.5, MacPython 2.3a2 (framework), wxPython 2.4.0.7, Boa 0.2.3. -- David Goodger http://starship.python.net/~goodger Programmer/sysadmin for hire: http://starship.python.net/~goodger/cv From Jack.Jansen@oratrix.com Tue Apr 29 21:49:38 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Tue, 29 Apr 2003 22:49:38 +0200 Subject: [Pythonmac-SIG] For your eyes only - MacPython-OSX binary distribution In-Reply-To: Message-ID: <17D2BE56-7A84-11D7-84F1-000A27B19B96@oratrix.com> On dinsdag, apr 29, 2003, at 19:19 Europe/Amsterdam, Russell E Owen wrote: > I just tried the binary installer and it ran fine. I really liked the > nice clear simple ReadMe file and the IDE help as well. > > The one problem I have is that it didn't install Tkinter. I'm going to make Tkinter available through the Package Manager. I'm not sure whether I'll be able to put Idle in the mix too, but we'll see. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From jhrsn@pitt.edu Tue Apr 29 22:44:50 2003 From: jhrsn@pitt.edu (Jim Harrison) Date: Tue, 29 Apr 2003 17:44:50 -0400 Subject: [Pythonmac-SIG] For your eyes only - MacPython-OSX binary distribution In-Reply-To: <17D2BE56-7A84-11D7-84F1-000A27B19B96@oratrix.com> Message-ID: My install of b1 on 10.2.5 went fine, too. I lost access to IDLE, which I had running on the last alpha with TCL/Tk, but other than that things seem OK. I, too, would love to see Boa Constructor running on OSX. Jim Harrison Univ. of Pittsburgh From lanceboyle@myrealbox.com Wed Apr 30 00:24:50 2003 From: lanceboyle@myrealbox.com (Lance Boyle) Date: Tue, 29 Apr 2003 16:24:50 -0700 Subject: [Pythonmac-SIG] Fwd: [Scipy-chaco] scipy/chaco package for OSX Message-ID: This message appeared a few days ago on the scipy-chaco list. I hope the author doesn't mind me forwarding it to this list. Jerry Begin forwarded message: > From: Jeffrey.S.Whitaker@noaa.gov > Date: Wed Apr 23, 2003 09:46:21 America/Phoenix > To: scipy-chaco@scipy.org > Subject: [Scipy-chaco] scipy/chaco package for OSX > Reply-To: scipy-chaco@scipy.org > > > Hi all: > > I've updated the fink (http://fink.sf.net) scipy package - it now > includes a working chaco using wxpython/wxgtk! > > The gtk/wxpython interface seems a bit peppier and more robust than the > native OS X interface at this point. > > To install it, update your package descriptions from cvs ("fink > selfupdate-cvs"), enable the unstable tree > (http://fink.sourceforge.net/faq/usage-fink.php#unstable) and "fink > install scipy-py23". > > Right now the package is only available for python23. > > > BTW: Here is what I get from scipy.test() on OS 10.2.5 with > python-2.3a2 > > Ran 739 tests in 18.147s > > FAILED (failures=70, errors=2) > > There are a lot of failures like this: > > ====================================================================== > FAIL: check_cdf (test_distributions.test_tukeylambda) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "", line 10, in check_cdf > AssertionError: D = NaN; pval = NaN; alpha = 0.01 > args = (1.2585851608415324,) > > from test.distributions > > and > > ====================================================================== > FAIL: check_nd (test_function_base.test_all) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/sw/src/root-scipy-py23-20030415-2/sw/lib/python2.3/site-packages/ > scipy_base/tests/test_function_base.py", > line 38, in check_nd > File > "/sw/src/root-scipy-py23-20030415-2/sw/lib/python2.3/site-packages/ > scipy_test/testing.py", > line 390, in assert_array_equal > AssertionError: > Arrays are not equal: > > from test_function_base. > > > -Jeff > > -- > Jeffrey S. Whitaker Phone : (303)497-6313 > NOAA/OAR/CDC R/CDC1 FAX : (303)497-6449 > 325 Broadway Web : http://www.cdc.noaa.gov/~jsw > Boulder, CO, USA 80305-3328 Office: Skaggs Research Cntr 1D-124 > > _______________________________________________ > Scipy-chaco mailing list > Scipy-chaco@scipy.org > http://scipy.net/mailman/listinfo/scipy-chaco >