🌐 Mailman 3 March 2005 - Pythonmac-SIG - python.org

Status of PyOXIDE
by Lance Boyle March 5, 2005

March 5, 2005

What is the status of PyOXIDE? This has looked extremely promising for a while, but the recent versions are very crashy. Jerry

1 0

[OT] To upgrade Mac OSX or not?
by Skip Montanaro March 4, 2005

March 4, 2005

This is probably a bit off-topic for this list, but is the only Mac-specific mailing list I subscribe to, and Mac OSX versioning seems to affect MacPython and many apps built with it. I was prompted to write after seeing Brian Lenihan's post about PySol for Mac OSX. Visiting the page I saw "10.3 only". *sigh* Yet another app I can't run on my laptop. Here's the rub. Apple seems to rather quickly drop support for what appear (numerically) to be minor releases. 10.1 is long gone. I have 10.3 on my G5 and 10.2 on my laptop. I'm loathe to buy 10.3 at this point for my laptop because 10.4 is in beta (right? Apple offered a preview version of 10.4 to me for $500 recently). I figure as soon as I buy 10.3, 10.4 final will be released. 10.3 will start to corrode and I'll be stuck again with "old" software once again. Only now I have two Macs, so the costs are double. It seems that Apple's upgrade policy almost forces me to buy new versions as soon as they are released. If I snooze when new releases come out I quickly get left in the dust and wind up either skipping a version or upgrading right before the next release. (This has happened to me in the past.) I really hate to say this, but in this respect backward compatibility in Windows seems to be much better. Am I missing something? Thx, -- Skip Montanaro skip(a)mojam.com http://www.mojam.com/

9 17

Getting stdin using TextWrangler or BBEdit, but not MacPython (was: [Pythonmac-SIG] One IDE can find sys._buf, the other can't. What's going on?)
by Louis Pecora March 3, 2005

March 3, 2005

Bob Ippolito wrote: > As far as this code goes, you might be able to just get away with it > if you do: > > # check for MacPython IDE > if hasattr(sys.stdout, '_buf'): > sys.stdout._buf = ... You're right this is a test that would shut off the _buf part of the code if I were not using MacPython. > > It really depends on what the rest of your code looks like. If it > does sys.stdout.readline() for example, it's still going to be broken, > because you can't normally read from stdout. The rawinput() function > might do what you want everywhere else, though. I can't seem to get rawinput or raw_input() to work. Ignoring my previous code. I just want something that can take standard input so, for instance, when I prompt with print "Input 2 ints and a float" The program will wait until I type, say 2 5 5.476 (return) Then hand back the three numbers either as a string, a list, or individual int and float types so I can process them with my program. Sort of like int i1, i2; float f1; scanf(" %d %d %e", i1, i2, f1); would do in C using stdin. Or even a gets() which I could then process to pull out the two ints and a float. I'm just looking for simple input of numbers and strings. I'd like to do this from BBEdit rather than MacPython. Anyone out there done this with TextWrangler? -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora(a)anvil.nrl.navy.mil

3 4

Re: Getting stdin using TextWrangler or BBEdit, but not MacPython
by Louis Pecora March 3, 2005

March 3, 2005

Charles Hartman wrote: > In TextWrangler something like this > while 1: > c = raw_input() > if c == 'quit': break > print c > works fine, if you choose Run in Terminal or Run with Debugger. If you > try to choose Output to New Window, it just quits immediately. But you > can certainly run it from within TW. Yes, that works. Thank you. I would have liked using the Output to keep it all in BBEdit, but I may have to go with the TW. Better than nothing. Thanks again. > > > Charles Hartman > Professor of English, Poet in Residence ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ And you program computers. Cool. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora(a)anvil.nrl.navy.mil

1 0

Re: [Pythonmac-SIG] CFURL Pain
by has March 3, 2005

March 3, 2005

Bob wrote: >>>Well I can verify that there definitely are serious problems with >>>CFURL after screwing around with it a bit. >> >>Figures. Yuck. Must be bgen's revenge for all the nasty things we >>ever said about it. > >All the nasty things I ever said about it are because of things like this :) But it's so quick! As long as you're Jack and know how to use it. If you're not Jack, I guess you're screwed. On second thoughts, given Jack's existing To-Do list is probably the size of K2 he's probably screwed too. :p I wonder if it'd be easier just to hand-code wrappers using Pyrex, perhaps with a very basic macro system that automates only the simplest of tasks. A lower level automation that works well might ultimately be more productive than total automation that tends towards flakiness. While a single person wouldn't be able to wrap nearly as many APIs, the wrappers that did get done would probably be more reliable due to the extra attention; maybe a bit nicer to use too. Plus it'd make it easier for more folk to write these wrappers, taking some pressure off Jack. >>>Too bad :) If you're writing Mac OS X specific code you >>>**really** should have PyObjC anyway. >> >>Oh, I have. It's all the casual users who don't that present the >>problem. If PyObjC is going to be so essential to all aspects of >>MacPython usage then it's really time for it to join the standard >>library. > >So let's offer a package that includes appscript, PyObjC, and py2app >in one installer. I do recall Jack saying something about maybe having a smaller core library and moving a lot of the non-essential stuff to an external package that could be managed independently; kind of a 'second tier'. Perhaps that would be the way to do it: more flexibility for individual package developers since they're not tied to the official Python upgrade cycle while still providing a quick and simple one-stop installation for users. Even modules that are destined for the core library would benefit from spending some time at this halfway house first while all the kinks are worked out (e.g. OSA.so). Might be worth exploring to see what sort of infrastructure it would require to run. HTH has -- http://freespace.virgin.net/hamish.sanderson/

4 17

One IDE can find sys._buf, the other can't. What's going on?
by Louis Pecora March 3, 2005

March 3, 2005

I ran some test code in the MacPython IDE and then from BBEdit (should be same as TextWrangle that some of you use). It runs in the Mac IDE, but I get this error in BBEdit: File "Drive:Users:louispecora:Code:python:general:general.py"; Line 132: AttributeError: 'file' object has no attribute '_buf' That line of code is this one import sys,Carbon sys.stdout._buf = say or '? ' # This line and the next print out the prompt 'say' <------ bad line I cannot figure this one out. I'm suspecting it's some sort of Python path or multiple Python version problem, but I have no clue. I am running OS X 10.3.8 on a 1.25 GHz PB. I was really enjoying the BBEdit approach since it is a great code editor and seemed to run generic stuff well until I hit this problem. Maybe I need to run that Panther stuff that fixes the Mac version. Any help greatly appreciated. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora(a)anvil.nrl.navy.mil

2 1

Re: [Pythonmac-SIG] CFURL Pain
by has March 3, 2005

March 3, 2005

Bob wrote: >FSSpec is legacy. It should not ever be used in any code except to >reference nonexistent files or to deal with legacy APIs. You >shouldn't use them if the API will take an FSRef or an Alias. Neither FSRef or Alias can be used to refer to non-existent files. FileURL does, but I'm not sure it can yet be used safely in place of FSSpecs in all cases, plus their standard Carbon.CF implementation is busted. FSSpecs suck, but I'm not sure they can be completely ignored just yet - any time I've tried to streamline aem/appscript to save the user from dealing with crap like this I've ended up having to re-expose it again in all its ugliness after something else ralphed on the 'clean and elegant' version. Rock, hard place. What's really needed is for MacPython to provide a standard high-level File class that abstracts over all this mess so module authors can have a solid and reliable API to implement against and end users don't normally need to futz directly with this stuff. No doubt an interesting and challenging problem for anyone that wanted to tackle it. > In this case, the API *asks* for an Alias. So, yeah, you do >actually want an Alias. No, the TextEdit dictionary says 'alias', but the dictionary is merely documentation, not the API itself, and dictionaries are regularly incorrect. It should almost certainly read 'file'. IIRC, the sdef format doesn't even list 'alias' as one of the standard primitive types, so I've no idea where TextEdit gets it from. Probably a blow on the head or something. Cocoa Scripting APIs are _also_ frequently buggy and ill-designed, and specifying files was one of its classic blunders in earlier incarnations which they've been trying to rectify ever since. So it is possible that they've buggered things up differently in 10.3 such that you do have to specify an existing file in a 'save' command; I don't have 10.3 so can't check offhand. If they have, I'm sure there's bugs filed on that as well, but I can't recall hearing anything about it. Nevertheless, 'save' commands have always traditionally accepted a file handle specifying an as-yet non-existent file for saving documents to a new file, and ignoring periodic Apple incompetence I don't believe this policy has formally changed for one moment. Apply one dose of healthy skepticism and a large dollop of plain common sense - both absolutely essential when it comes to Mac application scripting - and this should be obvious. has -- http://freespace.virgin.net/hamish.sanderson/

2 3

Re: OSA.so (was: Re: [Pythonmac-SIG] CFURL Pain)
by has March 3, 2005

March 3, 2005

Donovan Preston wrote: > > No, I wanted a Python OSA component. Different thing. The only person > > I know was asking for an OSA wrapper was Donovan, and he went off to > > work on Nevow yonks ago and AFAIK never did anything with it. > >I wanted an OSA module so that it would be possible to write a Python >OSA component using a more inside out approach. There's basically two halves to OSA. One half is used to implement OSA language components. The other half allows client apps to use them. OSA.so implements the API for the second of these, allowing Python to load and execute scripts written in any OSA language. The Carbon equivalent to Cocoa's NSAppleScript, except with a much more powerful and much less friendly API. To implement a PythonOSA component, you need to write a C wrapper around the Python interpreter's C API [1]. That wrapper then exports a bunch of callbacks (UUPs to be precise) that OSA calls to compile/decompile/execute/load/store/etc a Python script on behalf of a client. I don't think there's anything in OSA.so that'd help with that. I've been looking at OSA.so recently as I'd like to implement attachability in a PyObjC-based app I'm writing and NSAppleScript is too limited for what I want to do. While I've occasionally given the PythonOSA problem a passing glance, it's not something I'm as interested in solving myself as I haven't had any personal need for it to date and my C isn't good enough anyway. >I am still interested in producing a Python OSA component, hopefully >with the OSA module, but unfortunately it is a lot more work than I >have free time for at the moment. I lost my drive to work on it when it >became clear that HAS was far more energetic in this space than I was, >and HAS didn't seem willing to listen to what I had to say about the >subject or collaborate with anybody. I do remember being very grateful for advice when I was starting out on appscript. Can't recall ever being anti-collaborative or that; I may be abrasive and critical and behave differently to other programmers, but then I'm from a different background so maybe there was some accidental culture clash? Apologies if any offence was caused; it certainly wasn't intentional. Cheers, has [1] It might be possible to write a smaller C wrapper that allows you to install Python functions as callbacks for handling the compile/decompile/execute/etc. stuff within Python using exec and friends rather than doing the whole lot in C, which might be a bit more convenient than doing everything in C. I don't know enough about how the Python interpreter works to say if this would be practical or not. -- http://freespace.virgin.net/hamish.sanderson/

1 0

Using PIL/Compiling/_imagingtk
by Colby Gutierrez-Kraybill March 3, 2005

March 3, 2005

Howdie, I'm attempting to use the Python Imaging Library on a mac os x (panther 10.3.8) box with the standard python install, along with the macpython addons and the tcltkaqua packages. I first installed the macpython addons (http://ftp.cwi.nl/jack/python/mac/MacPython-Panther-2.3-2.dmg) for 10.3, then ran the package manager, which lead to a 404 error, and in-turn lead me to this post about the 10.3 package manager being unmaintained: http://mail.python.org/pipermail/pythonmac-sig/2005-February/013230.html I got the latest tclTkAqua-BI from: http://tcltkaqua.sourceforge.net/ (8.4.9.0) When I run python, I can now import Tkinter, and run a helloworld program to pop up a window, etc... The package manager, using Bob Ippolito's list http://undefined.org/python/pimp/darwin-7.2.0-Power_Macintosh.plist Specifies installing PIL from source, by hand... So, I got the latest 1.1.4 tgz from Pythonware, got through the ligImaging configure process but the make fails with: ... cc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -IlibImaging -I/Library/Frameworks/Tcl.framework/Headers -I/Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders -I/Library/Frameworks/Tk.framework/Headers -I/Library/Frameworks/Tk.framework/Versions/Current/PrivateHeaders -I/System/Library/Frameworks/Python.framework/Versions/2.3/include/ python2.3 -c _imagingtk.c -o build/temp.darwin-7.8.0-Power_Macintosh-2.3/_imagingtk.o In file included from /Library/Frameworks/Tk.framework/Headers/tk.h:96, from _imagingtk.c:20: /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:140: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:343: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:462: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:480: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:505: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:506: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:518: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:531: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:1065: warning: function declaration isn't a prototype gcc -Wl,-F. -Wl,-F. -bundle -framework Python build/temp.darwin-7.8.0-Power_Macintosh-2.3/_imagingtk.o build/temp.darwin-7.8.0-Power_Macintosh-2.3/Tk/tkImaging.o -LlibImaging -lImaging -o build/lib.darwin-7.8.0-Power_Macintosh-2.3/_imagingtk.so ld: Undefined symbols: _Tcl_AppendResult _Tcl_CreateCommand _Tk_FindPhoto _Tk_PhotoBlank _Tk_PhotoPutBlock_NoComposite error: command 'gcc' failed with exit status 1 Very Very Annoying... Based on other similar posts, this appears to be some recent inconsistency between the builds. Where do the above routines live and what's the proper direction to follow in getting some patch back to the 1.1.4 Imaging release to make sure this compiles? - Colby

2 1

malloc error with imaplib or socket on OS X
by Chris Miles March 1, 2005

March 1, 2005

Hi, I have recently come across what looks like a serious bug with Python on OS X. While writing a program using imaplib to connect to some IMAP4 servers I encountered a MemoryError exception with a malloc() error which was easily reproducible with my data at the time. The malloc error was: *** malloc: vm_allocate(size=9252864) failed (error code=3) *** malloc[1522]: error: Can't allocate region A thread on comp.lang.python shows that this bug has been encountered by others as well. http://groups-beta.google.com/group/comp.lang.python/browse_thread/ thread/cd5a8f28b021c269/cf7e574e3bc566df I tested my program on my standard OS X 10.3 Python (2.3) as well as a build of 2.4 and found the same MemoryError. (btw: I had plenty of free RAM at the time. Over 1/4 of 1GB on a powerbook G4) I tested the exact same program connecting to the exact same IMAP4 server (Exchange actually) on a Linux box and it worked fine (actually a Linux host running in VPC on the very same Mac). The data that was causing the MemoryError was a 9 MB mail message on the IMAP server. After I deleted this message the program on the Mac ran fine. The other messages were max 1 MB in size and there were about 114 of them. (The program downloads every message from a user's IMAP account, amongst other things.) Attached is a full Traceback of the MemoryError (as formatted by iPython). Is this a known issue, or should I submit it somewhere? Cheers, Chris -- Chris Miles http://chrismiles.info/

3 3