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
>