🌐 Mailman 3 December 2002 - Pythonmac-SIG - python.org

Extending python
by Matthew Smith Dec. 5, 2002

Dec. 5, 2002

Hello I need create a extension module, but am unsure as to how to go about doing it. Is using distutils the only way or is there an easier way? (os x specific maybe???) Also, can anyone point me in the direction of an example or two that can show me how it's done? Thanks, Matt Smith

2 1

Announce: OSATools
by Michael J. Barber Dec. 4, 2002

Dec. 4, 2002

The recent discussion of AppleScript and OSA inspired me to finally write a package I've been thinking about for a while. I'm calling it OSATools, and it basically is a set of wrappers for the 'osascript' and 'osacompile' OS X system calls. There are convenience functions for several cases, and a basic but useful class modeling an AppleScript interface. You can do things like: Python 2.2.1 (#1, 09/14/02, 00:14:43) [GCC Apple devkit-based CPP 6.02] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from OSATools import AppModels >>> finder = AppModels.AppleScriptApp("Finder") >>> finder.tell('get the name of the startup disk') 'Macintosh HD\n' >>> finder.tellBlock(['set countList to {}', ... 'set the end of countList to the count of the folder "Library" of the startup disk', ... 'set the end of countList to the count of folder "Applications" of the startup disk', ... 'return the countList']) '36, 88\n' >>> Written quickly and only tested a bit, so there are probably bugs. Seems to work ok, though. One caveat: OSATools uses pipes to talk to osascript and friends. In other words, it won't work with MacPython just yet, you need a Unix python. Anyone who is interested can get it here: <http://www.artsci.wustl.edu/~mjbarber/OSATools.tgz> Hope this is useful for someone. Michael

5 10

RE: [Pythonmac-SIG] How long until OS X Python is ready for primetime?
by Bugbee, Larry Dec. 4, 2002

Dec. 4, 2002

All this is goodness, but I wonder if we are speaking to David's original question. If I recall correctly, he has a large genealogy program and the most likely user is a "computer-challenged senior citizen". ...and that an *easy* download and installation is a must. I don't have any hard data, but most of the seniors I know are on a limited/fixed incomes causing 56K to be a lot more common than ADSL or cable. ..hence download size is a real factor. Most seniors that I know, and there are exceptions, are lucky to have a machine, let alone a fast one. ...and fast connections are equally rare. Larry -----Original Message----- From: Chris Barker [mailto:Chris.Barker@noaa.gov] Sent: Tuesday, December 03, 2002 4:05 PM To: David Eppstein Cc: Jack Jansen; pythonmac-sig(a)python.org Subject: Re: [Pythonmac-SIG] How long until OS X Python is ready for primetime? David Eppstein wrote: > Thanks (also to François Granger) for the feedback. I'd be willing to wait > a month if the solution is likely to meet my needs better, Note that you don't have to wait a month to start coding. All of the mentioned solutions are available for use now, even if they are a bit hard to install and get working. I think it's reasonable to be confident that it will get all sorted out enough for your purposes within a few months. Besides, with all the time you will save by not using C++, you can help with the effort! > but I'm a little > worried about the "add wxPython or Tkinter" part -- if my users have to add > that, it will significantly complicate the install process, but if I have > to add it myself, it will I assume bloat the download size. Yes, it will, and I warn you that wxPython is pretty large. However, you need to think about how important it really is to have a small download. 5MB is just not the barrier that it once was for most folks. Also, once tkINter gets stable, it is likely to be included with the default Python, maybe even by Apple some day. TKinter is considered part of the standard library other platforms. Having said that, I'd choose wxPython or TkInter based on which one fits your needs better, rather than getting too focused on an extra couple of megabytes of stuff to install. The real question is whether you need Cross Platform capability. By definition, anything cross platform is going to require some libraries that do not come with the system. This is true for C and C++ as well. IN fact, most of wxPython is actually wxWindows, the C++ library, which you would need for a C++ app as well. > Will try looking into PyObjC. I don't mind a few rough edges on the > developer side as long as the users don't have to see them. That being the case, you can get started right away. If you do want cross platform, I'd give wxPython a ggod look. All you need to do is download the Mach-O python (and wxMacPython itself) from the wxPython web site: http://www.wxpython.org/download.php#binaries -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(a)noaa.gov _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG(a)python.org http://mail.python.org/mailman/listinfo/pythonmac-sig

1 0

Using PyObjC to build production apps
by Bill Bumgarner Dec. 4, 2002

Dec. 4, 2002

On Wednesday, December 4, 2002, at 04:15 AM, pythonmac-sig-request(a)python.org wrote: > If you are developing a turnkey application I think I would suggest > PyObjC. It can build on the installed /usr/bin/python, and an > application in PyObjC will fit all your requirements (possibly with > the exception of the 2MB download, I'm not 100% sure of that). > Building a fullblown application with PyObjC still has a few rough > edges, but they're being ironed out quickly. As Jack mentioned, there are a couple of rough edges, but PyObjC is definitely a viable means of building standalone GUI applications targeted to MacOSX in Python. If you do decide to delve deeper into PyObjC, please grab the source/examples/etc from pyobjc.sourceforge.net. The current repository contents is way better than the last released version-- many bug fixes, many enhancements to make the programming experience considerably easier and more powerful. Ronald Oussoren has made the interaction between ObjC and Python significantly more seamless and bullet proof than the last release; he has gone so far as to identify and workaround some very subtle/nasty bugs in certain AppKit classes. The examples contained in the repository provide an excellent starting point. In particular, the Web Services Tool and TableModel2 provide complete examples of building PyObjC applications using Project Builder as the IDE. There are also examples that demonstrate building applications without using PB. Just van Rossum has done an incredible job of providing tools to the PyObjC project. In particular, Just contributed a mechanism via which classes defined in interface files [NIB files] are automatically created when the NIB file is loaded. That is, the entire step of keeping your source files in sync with your interface files has been eliminated-- "it just works". In this context, it is less work to build a PyObjC based Cocoa app than a Java or ObjC based Cocoa app! Personally, I'm using PyObjC to build two production quality applications, one of which is relatively complex [it is really a suite of applications that share two frameworks -- one framework of which is almost entirely implemented in Python with a PyObjC bridged layer that the rest of the app uses]. I chose this route not because I like living on the bleeding edge, but because using PyObjC cut a huge amount of gnarly, bug prone, code out of my project and the end result is a more robust applications that performs every bit as well as a pure-C/ObjC counterpart. (Specifically, I replaced the entire web services layer of my application with a python implementation of the web services client. As an added advantage, my python based web services client now works seamlessly across all operating systems / platforms, yet my OS X GUI client remains a pure Cocoa/OS X UI experience.) Very cool stuff -- we have come a long, long way since PyObjC '96! b.bum

1 0

Re: [Pythonmac-SIG] Announce: OSATools
by Michael J. Barber Dec. 4, 2002

Dec. 4, 2002

On Wednesday, December 4, 2002, at 09:22 AM, Jack Jansen wrote: > > On Wednesday, Dec 4, 2002, at 10:15 Europe/Amsterdam, Michael J. Barber > wrote: >> Divorced from a real problem, it's a bit difficult to find a good >> example that is interesting, succinct, and (perhaps most importantly) >> uses an application that everyone has. Any suggestions? > > How about an example that remembers (and re-creates) your finder window > configuration? I.e. it goes over the open windows, remembers where they > are on schreen and what they're displaying. An accompanying routine > will take the data produced by this and opens and positions new > windows, etc. > That seems quite doable. I'll put that together if I've got a free moment this evening. Keep 'em coming folks!

1 0

On more framework to mention...
by Daniel Lord Dec. 4, 2002

Dec. 4, 2002

David, Depending upon the performance you require and the access to the system you require, Jython might be viable. Since Jython is Python it is a rapid-prototyping scripting language that is still adequate for some productions applications. And it has the advantage of Python in that it uses a standard GUI that is easily available for many platforms, Java AWT and Swing. It works well on OS X from what I have seen and performance is a lot better with Hot Spot (Java's built-in compiled module caching technology). Just another option you might consider. Daniel Lord -- daniellordATtelocityDOTcom GPG Fingerprint: C59E 59F5 1C63 5CFB 6161 067E FF00 A4E8 684A 16BB "The purpose of separation of church and state is to keep forever from these shores the ceaseless strife that has soaked the soil of Europe in blood for centuries." [James Madison, 1803]

1 0

Warning for CVS users: another mass checkin coming
by Jack Jansen Dec. 3, 2002

Dec. 3, 2002

A warning for people tracking CVS: there's another mass checkin coming for the Carbon modules. When this is in all Carbon types will be PEP253-compliant. This means that you can subtype the Carbon types from Python (and from C). This is all very exciting, but for the time being I won't guarantee that your code won't break. -- - Jack Jansen <Jack.Jansen(a)oratrix.com> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -

1 0

Database engine
by François Granger Dec. 3, 2002

Dec. 3, 2002

On the Spambayes mailing list there was a discussion about the quality of the current bsddb database engine on Windows platforms. I was asked the question of how it is on Mac OS9 side. All I could say is that anydbm rely on gdbm. But I don't know which engine it is. Anyone knows a little on this ? -- Le courrier est un moyen de communication. Les gens devraient se poser des questions sur les implications politiques des choix (ou non choix) de leurs outils et technologies. Pour des courriers propres : <http://marc.herbert.free.fr/mail/> -- <http://minilien.com/?IXZneLoID0>

2 1

Re: Ru Ro
by Bill Bumgarner Dec. 3, 2002

Dec. 3, 2002

And we are [thanks in large to Ronald] way ahead of the Ruby or Perl bridges... we do subclassing, we handle complex structures, we transparently work with PB.... ... we *really* need to cut a new version. I'm going to go ahead and do so at end of week regardless of state --- call it 0.8.0 -- assuming nothing is horrendously broken. On Tuesday, December 3, 2002, at 12:00 PM, pythonmac-sig-request(a)python.org wrote: >> RubyCocoa is a Ruby library for using Cocoa Objects on Mac OS X

1 0

[Tutor] Rut Ro... (fwd)
by Danny Yoo Dec. 2, 2002

Dec. 2, 2002

Hi darksyyyde, You asked about using Cocoa on Python-tutor, but your question may be more suited to the pythonmac-sig, since it is a bit specialized. I'll forward it off to pythonmac-sig for your convenience. The people on pythonmac-sig should know more about getting Cocoa and Python to work nicely together, and I hope you get some good answers. Best of wishes to you! ---------- Forwarded message ---------- Date: Fri, 29 Nov 2002 11:32:44 -0700 From: darksyyyde <darksyyyde(a)earthlink.net> To: tutor(a)python.org Subject: [Tutor] Rut Ro... RubyCocoa is a Ruby library for using Cocoa Objects on Mac OS X http://www.imasy.or.jp/~hisa/mac/rubycocoa/ Why hasn't Python done something like this?? I haven't been able to get tkinter to work with OSX, and Python libraries for using Cocoa Objects would make it irrelevant. And far superior. The above link has a nice screen shot of a simple app written in Ruby that uses the OSX Cocoa GUI. _______________________________________________ Tutor maillist - Tutor(a)python.org http://mail.python.org/mailman/listinfo/tutor

5 4