🌐 Mailman 3 October 2000 - Pythonmac-SIG - python.org

Re: [Pythonmac-SIG] Line endings and readline()
by Jack Jansen Oct. 5, 2000

Oct. 5, 2000

Recently, Chris Barker <cbarker(a)jps.net> said: > Andrew Watson wrote: > > Is there some easy way of convincing python to change what it expects as th > e > > end-of-line character, to deal with this sort of crodd-platform problem? > > No, and I wish there was. There are some cases where it can be useful, but in general you should leave this to whoever did the transfer from mac to unix or vice-versa. After all Python isn't the only Unix program that'll have trouble with Mac line endings: all unix programs will. FTP clients, archivers, and remote file server packages will usually do the conversion for you if you set them up correctly. And on the Mac this should be a breeze because all files of type TEXT should be translated (unix and windows programs will have to gues whether a file is text based on the extension, so you'll have to do the correct setup there yourself). A quick trick for converting any known convention to \n convention is the following (if you can afford reading your whole file into memory) data = f.read() data = string.replace(data, '\r\n', '\n') data = string.replace(data, '\r', '\n') It'll even work for confused files, as you can often find in webpages and such that have been edited on multiple systems. The only thing it won't handle is files with \n\r (which can happen if you send a file back and forth between all three platforms and don't get the conversion right), but this is unsolvable anyway. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

3 3

Restart confliect
by Adam Oct. 4, 2000

Oct. 4, 2000

Has anyone else had problems with restarting their Mac when Python is on an external drive? On my system (8.1 and LinuxPPC launched by BootX) I have Python on an external drive and it works fine, but... The machine cold boots fine, but on restart it freezes on the happy mac. No such problem if it is on my boot drive. I assume the problem is ith the fact that Python Core is an alias in the extensions folder and the machine is trying, unsuccesfully at that stage, to find the original. Any thoughts on a work around would be appreciated. Cheers, Adam

1 0

Re: [Pythonmac-SIG] Darwin vs. OSX (was: Python on Mac OS X w/shared modules)
by Tony Lownds Oct. 4, 2000

Oct. 4, 2000

At 01:03 PM 10/4/2000 -0400, Steven D. Majewski wrote: >On Wed, 4 Oct 2000, Martin v. Loewis wrote: > > > > > > a) fixes the platform recognition code in configure (and > configure.in) to > > > recognize Mac OS X as "darwin/1.2" > > > > I'm confused. I thought that darwin was the name of a free BSD > > personality on top of MacOS X, and that the "official" MacOS X tools > > are different from the Darwin ones. Is that the case? and do the > > official tools behave like the Darwin tools for building Python. > > > ... >There are free Darwin development tools -- gnu based with a lot of >Apple mods -- which will work on either Darwin or the full OSX. >But it doesn't have all of the nifty Next-like graphical development >tools -- ProjectBuilder, et.al. or all of the higher level Mac >environment libraries. The gnu Darwin development tools will be used by the higher-level ProjectBuilder et.al. so the official tools should act the same. I made Mac OS X recognizable as "darwin/1.2" because thats what hostinfo says. >There is a MacOSX beta developer kit that is going to be available >free online, but is now only sent to regi$tered developers, which >contains both all of the gnu/unix development environment plus all >of the apple specific development tools. Should be available by the middle of the month! >With the shared libraries working, it ought to be possible to build >one Python executable with dynamic libraries for both environments: >i.e. users running "vanilla" Darwin are probably running X11,Gtk,Tk, >etc. ODX users will have the Mac libraries. ( There's a commercial >rootless X under Mac OSX server, and eventually, I expect XFree86 >to be modified so you can have X11 and MacOS graphics environment.) I think it will be really challenging to integrate the two different ports; the pretty trivial generic UNIX to Darwin conversion and the decidedly non-trivial Carbonized MacPython In the scenario you describe above there could be two totally different but valid _tkinter.so files to load! Actually I don't think the Tk people have done a lot of work on Mac OS X yet, so that may not be an issue for a while... -Tony

1 0

'.pyc' and pathnames
by Etienne Antoniutti Di Muro Oct. 4, 2000

Oct. 4, 2000

Dear list members, I am distributing a C++ application with embedded python modules. I'm using PythonCore from Python1.5.2c2src distribution. I do distribute: 1- the C++ binary 2- PythonCore 3- Python essential modules + my embedded modules (.pyc only -not plain .py - compiled on a developping-Mac ). During debugging and Python error tracebacks I notice that Pythno refers to modules using pathnames coming from the specific filesystem of the developping-Mac (i.e: "MyMacintosh HD: [.....] : My_path_to_the_embedded_modules:my_embedded_module.py") But if no bug is found and the c++ application doesn't get corrupted and terminates correctly, everything works fine. If I do debugging on a user-Mac (different from the one I compiled to .pyc the embedded modules) tracebacks report the same pathnames. This makes much sense, but shoud I warn about that?? Python1.5.2c1 pyc files are machine dependent?? thanks in advance etienne -- it's time to leave this town it's time to steal away let's go get lost anywhere in the U.S.A. (RHCP)

1 0

W applications
by Tattoo Mabonzo K. Oct. 4, 2000

Oct. 4, 2000

Yo, Is it correct that the fact that W relies on globals such as _application and _signature makes it (essentially) impossible to have several W-based application running at the same time? TIA for any input! = tmk =

3 2

Some Questions...
by Jacob Kaplan-Moss Oct. 3, 2000

Oct. 3, 2000

Hello PythonMac-Sig! I've been using MacPython for about a year now, and I've run into some questions: 1) Are there other people out there doing serial port communication? If so, what are you using? I'm currently using the ctb module, which I suppose works, but doesn't provide everything I want to do. 2) I know that Jack mentioned a while ago that he had used the Qt module to grab frames from a movie file. I want to do something a little different: grab frames (or posibly movies) from a video digitizer. I have the code from the QuickTime SDK to do this in C, but I wonder if it can be done in Python with the Qt module. If so, has anyone done this? 3) Also, has anyone used QuickTime's MIDI interface? Is this exported through the Qt module? (I guess what I'm really asking for is some documentation for the Qt module. I've read the postings about the new MacPython documentation effort, but it's been quiet on that front for a while now...) 4) Does anyone have or know of any examples of applications using the FrameWork and W modules (besides the IDE)? I've decided to use FrameWork/W instead of Tkinter (because of the extreme instability of Tkinter); but I'm having a hard time getting started. Thanks in advance! Jacob Kaplan-Moss

1 0

AppleScript Guru Wanted
by Vincent Marchetti Oct. 3, 2000

Oct. 3, 2000

Recently, Jack Jensen posed two problems with scripting Mac applications through OSA: >Hi folks, >I just ran into a problem with MacPython OSA support. Two problems, >actually: >1. The CodeWarrior suite declares both a property "project document" >and a class "project document". As you wil understand this does not >work well, as these both end up in the same namespace, and both with >the same name "project_document". Is it legal OSA to have properties >and classes with the same name? If it is: can anyone think of a >workaround for MacPython? > I at first replied that I had problems with apps I had written, in which I shared names between AppleEvent classes and properties. It appears that the scripting interface to CodeWarrior has this sharing as Jack explains above. I have since checked, and it appears that the interface to CodeWarrior DOESN'T WORK!. That is, when I try in AppleScript (via the Script Debugger) to try this script: tell application "CodeWarrior IDE 4.0" get project document of target 1 of front document end tell No result is returned, no result and no error. However, when the property "project document" is explicitly specified, as in: tell application "CodeWarrior IDE 4.0" get «property PrjD» of target 1 of front document end tell the appropriate object reference is returned. I think it's fair to say that such name sharing is not supported in AppleScript, and it doesn't seem to make sense to jump hoops in a Python scripting system to allow it. I have also looked back at my own apps that tried to share names, and I saw that I had to do some kludgy things in the Apple Event handling to decode the events sent by AppleScript. >2. Aepack does not handle passing classes as arguments. If anyone >feels like fixing this: please be my guest. The symptom is that if you >do "xxx.make(new=classname)" it should pass >aetypes.Type(classname.wantd). Hmm, maybe if this is fixed the >previous problem isn't a problem anymore.... Oh sigh, my brain always >turns inside out when I try to reason about OSA:-( > >Any help is appreceated, I at first replied that I just use xxx.make(new = classname.want) but I now realize that this assumes that the receiving application is clever enough to convert the 4 character 'want' string to an Apple Event type, and apps written using the Metrowerks PowerPlant framework are this clever. However, a better solution is to add the following choice to the long list of choices in the pack function from module aepack: def pack(x, forcetype = None): ... t = type(x) ... # add this to correctly pack class specifications if t == ClassType and issubclass(x, aetypes.ObjectSpecifier): # issubclass Python builtin function return aetypes.Type(x.want).__aepack__() # end of class specification packing ... This change allows the syntax Jack suggests above. Vince Marchetti

1 0

pyxml binaries for Mac
by Nick Collier Oct. 2, 2000

Oct. 2, 2000

Hi, Is there somewhere I can get pyxml binaries for a Mac. thanks, Nick -- Nick Collier Social Science Research Computing University of Chicago http://repast.sourceforge.net

1 0

MiniAEFrame.py masking TypeErrors in AE handlers (2.0b1)
by Tattoo Mabonzo K. Oct. 2, 2000

Oct. 2, 2000

Yo, I've run into an inconvenience which I've never had before. I'm not sure if this is due to something that changed in PythonMac 2.0b1. I'm getting the following stacktrace: --- cut Traceback (most recent call last): File "DD_Dev_Apps:root:cgi-bin:py:PythonProxyApplet.py", line 60, in __init__ self.mainloop() File "DD_Dev_Apps:Python 2.0b1:Mac:Lib:lib-toolbox:MiniAEFrame.py", line 55, in mainloop self.dooneevent(mask, timeout) File "DD_Dev_Apps:Python 2.0b1:Mac:Lib:lib-toolbox:MiniAEFrame.py", line 63, in dooneevent self.lowlevelhandler(event) File "DD_Dev_Apps:Python 2.0b1:Mac:Lib:lib-toolbox:MiniAEFrame.py", line 72, in lowlevelhandler AE.AEProcessAppleEvent(event) File "DD_Dev_Apps:Python 2.0b1:Mac:Lib:lib-toolbox:MiniAEFrame.py", line 150, in callback_wrapper raise TypeError, ('AppleEvent handler misses formal keyword argument', _function, name) TypeError: ('AppleEvent handler misses formal keyword argument', <method PythonProxy.handle of PythonProxyApplet instance at 0x0d27c880>, <exceptions.TypeError instance at 0x0d27dc00>) --- cut The problem is that the TypeError exception was thrown due to a bug of mine within some code executing in the handler, so the message is quite misleading (ie there are no missing formal keyword argument). In effect, the except clause @ line 150 in MiniAEFrame.py is masking TypeError bugs in the AE handler code. From the docs: "raise_stmt: "raise" [expression ["," expression ["," expression]]] [snip] If a third object is present, and it is not None, it should be a traceback object (see section 3.2), and it is substituted instead of the current location as the place where the exception occurred. This is useful to re-raise an exception transparently in an except clause. " Thus, I'd suggest adding sys.exc_traceback as the third argument to the raise statement (as possibly in other places with similar context?). Besides, as you can see from the stacktrace, due to the subtle rules of conversion of Python objects to string (repr vs. str), the user gets to see the 'type' of the exception object instead of the more useful error message (e.g. 'no arguments expected'). Thus, I'd suggest using <str(name)> instead of <name> (or even better, str(sys.exc_value)) as the second of the arguments tuple for the class instanciation and maybe also change the error message I'm not sure how this was handled (no pun) in PythonMac 1.5.2c1 but I've not encountered this problem with it (It may be that I've never had a type error bug in a similar context in 1.5.2c1 but that would be amazing :-). TIA = tmk =

1 0