🌐 Mailman 3 February 2004 - Pythonmac-SIG - python.org

How to find correct Carbon module(s)?
by Dinu Gherman Feb. 26, 2004

Feb. 26, 2004

Hi, I try to use some Carbon packages with vanilla Python 2.3, but I'm having trouble to find the right Carbon libs to import... Does anybody have a hint as of what to import to make the Carbon functions and constants below work in Python 2.3? Thanks, Dinu // mainWindow = ... void *ref = [mainWindow windowRef]; BOOL flag = YES; if (flag) ChangeWindowAttributes( ref, AM_kWindowIgnoreClicksAttribute, kWindowNoAttributes); else ChangeWindowAttributes( ref, kWindowNoAttributes, AM_kWindowIgnoreClicksAttribute);

5 9

python ide problem
by LALOUX Martin Feb. 26, 2004

Feb. 26, 2004

Not connected to Internet at home, i install python modules whith : python setup.py etc... The modules are placed in Library/python I was able to install many modules and Ide as Dr Python, Boa etc which work very well Accustomed to other Python environments (pycrust) I seldom use "Ide Python" but since few days, when i try to launch it, it crash . When i launch from terminal the script: "/usr/bin/pythonw" "/Applications/MacPython-2.3/PythonIDE.app/Contents/Resources/PythonIDE.py" I have this message "IndexError: list index out of range" (with Wapplication.py) All other ides or python scripts work without problem Thank-you very much for the help Martin Laloux

2 1

Re: Newbie path problem
by Christer Fernstrom Feb. 26, 2004

Feb. 26, 2004

I have just ported some of my own python code from os x 10.1 to Python 2.3 on OSX 10.3 and come upon a problem with the path which would surprise me if not several others have. One module imports another module residing in the same directory, which is not on the PYTHONPATH. This works fine when running from the terminal, and it used to work fine in my earlier installation also after using BuildApplet to create an application applet. This does not work in Python 2.3. Instead it generates an import error. Tracing sys.path, I notice that its first two elements are equal: <scripts-directory>/<scripts-name>.app/Contents/Resources Inserting an empty string in os.path before importing, which according to the documentation should help, doesn't help (maybe because os.environ does not contain any definition of CWD - current working directory - either). The only thing that works is manually inserting the correct directory into sys.path before doing the import. Not very elegant if you want to install the code in a different place. -- christer

2 1

Re: [Pythonmac-SIG] Re: [pygame] python + pygame on OSX
by Keith Nemitz Feb. 25, 2004

Feb. 25, 2004

> > In any case, it is an extremely bad idea to write to the application > bundle, and that may have something to do with your trouble. The > appropriate place for writing files would most likely be > "/Library/Application Support/YourApplication" or > "~/Library/Application Support/YourApplication", unless they are plist > preferences.. > I think it would be an extremely good idea to allow an app to be able to write to itself. Currently, my app is 100% cross platform, thanks to the good people at py*. Now I'm going to have to sully my hands again with religious doctrine and programmer machismo. sigh, Keith Nemitz <-- sick of it all, after eight years of porting apps.

4 6

Capturing system screen pixels on OSX
by tburbage3＠excite.com Feb. 24, 2004

Feb. 24, 2004

I'm experimenting with a means via Python to capture a rectangle of the screen for the purpose of software/UI testing. I'm using Python because I need a cross-platform solution: Windows, OS10.3.x -- eventually Linux. I'm using the latest "stable" versions of Python and the packages mentioned below. Jack (Jensen), I have your stuff installed and working, and also used the database from <http://undefined.org/python/pimp/> to get all of the packages installed properly. The script currently uses: OpenGL.GL, OpenGL.GLUT -- to establish a graphics context/display mode (RGB/single buffer) and gain access to pixel data in the framebuffer.Image (PIL) -- to save the buffer contents to file. The script specifically uses GLUT's 'glutEnterGameMode()' to establish the full screen as the viewport, then uses glReadPixels() to get the desired capture subregion (rect). This script works perfectly on Windows, but on OSX I end up with (seemingly) random RGB values.The script makes one critical assumption that on Windows at least is true: that when GLUT establishes it's graphics context and "takes over the screen buffer" the contents of the front buffer ARE the current screen contents until glClear() is called or some other drawing operation is done. Needless to say, there could be alot of reasons why my approach isn't working on OSX, so I thought it time to ask folks in the community familiar with graphics programming on OSX whether the approach I've generally describes sounds like it *should* work (meaning I might just need to keep tweaking) or that there might be a more effective approach. Thanks,Tom BurbageRedwood City, CA _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web!

1 0

Re: [Pythonmac-SIG] Re: [pygame] python + pygame on OSX
by Keith Nemitz Feb. 24, 2004

Feb. 24, 2004

I'm currently developing a standalone app for OS X. I use a data folder in the resources folder to contain all of my app specific files. Now, from what I've read on this thread, it sounds like I should be experiencing access/permission difficulties. My app has run on three other Macs, and I just started having trouble with the third one. I think it might be an access issue, but I haven't confirmed it. My app reads and creates files in its data folder. Keith Nemitz Mousechief

2 1

Plea for function/method syntax sugar (PEP 318, with a different syntax)
by Bob Ippolito Feb. 24, 2004

Feb. 24, 2004

Some time ago, mwh developed a patch that adds some syntactical sugar to def, which is equivalent to PEP 318 though it has a different and more flexible syntax... previous threads can be easily found here: http://www.google.com/search?q=+site:mail.python.org+%22meth-syntax- sugar%22 the latest version of mwh's patch is here: http://starship.python.net/crew/mwh/hacks/meth-syntax-sugar-3.diff Here's a quick overview: def foo(args) [sugary, expressions, list]: pass This is equivalent to: def foo(args): pass foo = list(expressions(sugary(foo))) This evaluation order is Guido approved, though at least one person wanted it to be the other way around One would use this in scenarios such as: class FooClass(object): def className(klass) [classmethod]: return klass.__name__ or, even more importantly (to me anyway): # we would change PyObjC to make this a built-in feature.. but, for completeness: import objc def signature(sig): def _signature(fn): return objc.selector(fn, signature=sig) return _signature class FooClass(NSObject): def returnsAnInteger(self) [signature('i@:')]: return 1 def returnsVoidTakesAnInteger_(self, anInteger) [signature('v@:i')]: pass With current syntax, PyObjC is extremely cumbersome: class FooClass(NSObject): def returnsAnInteger(self): return 1 returnsAnInteger = objc.selector(returnsAnInteger, signature='i@:') def returnsVoidTakesAnInteger_(self, anInteger): pass returnsVoidTakesAnInteger_ = objc.selector(returnsVoidTakesAnInteger_, signature='v@:i') # these are actually short examples, compare to something like: # textView_completions_forPartialWordRange_indexOfSelectedItem_ Why we need this: Without it, it's hard use PyObjC correctly. ObjC selector nomenclature is extremely verbose, and your fingers hurt after a while having to type each function name three times. The function __name__ is important, because the objc.selector type has to convert it to a selector:that:uses:colons:, or else the colon:using:name: would have to be specified manually. It makes classmethod/staticmethod/etc more palatable. What the patch doesn't do: lambda is not allowed in the "sugary expressions list" there's no *expansion and it won't take an actual list so if you want a prebaked list of transformations then you'll have to roll a callable that does it such as: def prebake(*expressions): def _prebake(fn): for transformation in expressions: fn = transformation(fn) return fn return fn This syntactical sugar for def is so unbelievably important to PyObjC (and likely other projects) that I am willing to distribute my own modified version of Python if it doesn't make 2.4 (though I would probably use Stackless as the base, but that's another plea for another day). The patch looks like it still applies to CVS HEAD, but there is a little fuzz on hunk 2. I have not tested it yet, but I have tested it against CVS HEAD of the 2.3.3 based Stackless. I'm willing to help however I can in order to get this into Python 2.4. -bob

4 5

Use Quartz - CoreGraphics to Rotate PDF
by Tim Conner Feb. 24, 2004

Feb. 24, 2004

I've got another CoreGraphics question. I've been pooring over the help that I got on my last request for a pdf concatenator subroutine. Gus had the best solution for my needs, and he posted it to his weblog here: http://www.gusmueller.com/blog/archives/2004/2/18.html#1027 - thanks for all the help everyone. My second quest is to right a script that will look at the dimensions of a pdf and determine if it's landscape or portrait, and rotate it conditionally. Eg, if landscape, rotate to portrait. What I'm looking for from you pros is just an example of a pdf rotation using CoreGraphics, or what calls to use to achieve a rotate of a 1 or many paged document. Thanks, Tim

1 0

Re: Swig_for_Mac
by Christopher Smith Feb. 24, 2004

Feb. 24, 2004

> I'm trying to use an extension I've downloaded (APSE, a "Python port > of the String::Approx module written for perl by Jarkko Hietaniemi."). > I downloaded Swig_for_Mac 1.3.11 and am trying to figure out how to > make one of the examples work before I try to process the apse.c file. > > I start up Swig_for_Mac and set the source to be the example.i file > and press run. A wrapper file is produced, example_wrap.c. > > Now I don't know what to do from here. I am having a hard time sifting > out what can/should be done with the Swig_for_Mac and what must be > done at the command line with gcc. > Thanks very much to those that sent suggestions as to what I should do to get Swig working under OS X. It was a large but not insurmountable learning curve, having been a mac user for many years, but not a seasoned unix user. For the record (and for anyone else like me) I report the following steps that I took to get the APSE extension working. (I abandoned work with Swig_for_Mac in favor of the unix swig.) * downloaded and installed the developer tools (Dec 2002 version) from Apple; without these, I got a "configure: error: C preprocessor "/lib/cpp" fails sanity check" under certain conditions and was told that the "string.h" file was missing under other conditions. * restarted the computer * downloaded the swig-1.3.20 file and installed that per unix instructions; this installed a binary in /usr/local/bin * issued the swig command (even after restarting) and got a "swig: command not found" error. This was remedied by editing (actually creating) a file named ".login" in my home directory containing (as suggested at http://forums.osxfaq.com/viewtopic.php?t=3012): set path = (. \ -/bin \ /Developer/Tools /Develooper/Applications \ /usr/local/bin /usr/bin /bin \ /sr/local/sbin /usr/sbin /sbin \ ) * threw away my old folder with the Apse failed work in it and re-unstuffed the Apse-0.1.tar file (with Stuffit Expander) on the desktop * started the "terminal" program; changed to the Apse directory (cd ~/Desktop/Apse-0.1) and issued the commands as in the readme: csmith% python setup.py build csmith% python setup.py install * and began using the Apse extension :-) Since this was the first time that I have built an extension, I had no idea that I needed the developer tools to do it. There was certainly a large chasm between me as a Mac user, and recent Python user and me as someone able to add to Python from other's extensions. I wonder if those of you that write extensions might include a few extra lines in your readme about building the extension under os x so as to point out that the developer tools and (perhaps) swig are necessary to build your extension. Without the input from a few others on the list here I would have been totally lost.

1 0

Using IDLE to run Tkinter programs in OS X?
by Kenneth McDonald Feb. 24, 2004

Feb. 24, 2004

Is there any way to have IDLE use pythonw, rather python, when it runs modules, so that I don't get the -606 error when working on programs that use Tkinter? Also, I'm curious if the "OS X look" in Aqua Tcl/Tk is a result of a "themable" ability in Tk, or is a special case thing for OS X only. I haven't used Tk for a number of years, and at the time, it had only one "look". Thanks, Ken McDonald

2 1