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

Mac User Python Newbies
by Brendan Simons Feb. 17, 2005

Feb. 17, 2005

The IDE thread is a recurring one. Here's my experience as another Python newbie. I tried SPE, PythonCard, PyOxice, PyPE, eclipse and wing (under x11). All work, but I found that each one had enough quirks (mostly UI inconsistencies, but some are downright unstable) that I was less productive than without. Not to sell any short, I'm sure they will get better given time. FWIW, the winning formula for me right now is: 1) Editor: TextWrangler (http://www.barebones.com/index.shtml). -Free, "Made For Mac", Code Colouring, Method Indexing, The ability to run scripts from the editor, More text manipulation options than I can count. 2) GuiEditor: XRCed.py (comes with the wxPython install package). (Or code the wxPython by hand, which takes longer, but gives you a little more control over the result). 3) And an instance of terminal running python interactive mode. Actually, this is the most valuable Python tool I've found so far - it's like a scratch pad where I can quickly check assumptions, or test out ideas. The only thing I'm missing now is a debugger with breakpoints, call stack, and variable watches. I'll have to settle for random print statements for now. -Brendan On 8-Feb-05, at 11:06 PM, pythonmac-sig-request(a)python.org wrote: > > If you try SPE, I'd be very interested to hear your results. It's > beautiful, and very extensive. But I have not been able to make it > work. (The same has been true for me with wxGlade. It may be my fault, > or the fault of my system.)

10 28

pythonw
by Chris Fonnesbeck Feb. 16, 2005

Feb. 16, 2005

Sorry in advance for what may, in fact, be a naive post, but I am trying to figure out the significance of pythonw on OSX. I know that you need to run pythonw if you intend to use python programs with certain graphical backends, otherwise the UI becomes unresponsive. Running idle from the command line, for example, starts an instance of idle that is unusable. My question is: why have both python and pythonw? When would you ever *not* want user interfaces not to work? This problem does not arise on other platforms, does it? Its a bit of a hassle, at the moment, to try and figure out when to use one or the other. Are there any plans to remove this apparently unnecessary dichotomy? Thanks for any information, Chris

4 5

[ann] Appscript Installer 1.0
by has Feb. 16, 2005

Feb. 16, 2005

Hi all, Announcing the first release of the all-in-one Appscript Installer package for Mac OS X 10.3. Appscript brings AppleScript-quality application scripting support to MacPython on Mac OS X. This package installs everything you need to control "Applescriptable" applications using the Python 2.3 runtime included as standard in Mac OS X 10.3. In addition to a clean, easy-to-use, object oriented-like syntax for scripting applications, appscript also includes powerful built-in help facilities for exploring applications' terminology and object model - features normally found only in high-end commercial AppleScript editors. To download Appscript Installer, please visit the appscript webpage: http://freespace.virgin.net/hamish.sanderson/appscript.html To see some examples of use: http://freespace.virgin.net/hamish.sanderson/appscript_examples/index.html If you have any questions or comments, please don't hesitate to get in touch. We're still working to polish appscript and finish its documentation, so all feedback is greatly appreciated. Enjoy! has -- http://freespace.virgin.net/hamish.sanderson/

4 5

another query about IDE
by Charles Hartman Feb. 16, 2005

Feb. 16, 2005

In that long discussion, someone mentioned jEdit, so I went and looked it up. It looks very promising and robust. But am I right in thinking that the only path toward GUI apps that it would support would be Java (JPython) based? Rather than wx, and so on? Charles Hartman

3 2

MySQL-Python Help
by Jason Vance Feb. 16, 2005

Feb. 16, 2005

I'm pretty new to python development on the Mac. I'm not sure that if this is the appropriate place to place this question, but I'm having problems getting the MySQL-python v1.2.0 working on my mac. When I try and set it up, as per the instructions I get the following errors: jasonvance$ python setup.py build running build running build_py running build_ext building '_mysql' extension gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I/sw/include/mysql -I/System/Library/Frameworks/Python.framework/Versions/2.3/include/ python2.3 -c _mysql.c -o build/temp.darwin-7.8.0-Power_Macintosh-2.3/_mysql.o -I/sw/include/mysql -O3 -fomit-frame-pointer In file included from _mysql.c:31: pymemcompat.h:10:20: Python.h: No such file or directory _mysql.c:40:26: structmember.h: No such file or directory _mysql.c:59: error: parse error before '*' token _mysql.c:59: warning: type defaults to `int' in declaration of `_mysql_MySQLError' _mysql.c:59: warning: data definition has no type or storage class _mysql.c:60: error: parse error before '*' token _mysql.c:60: warning: type defaults to `int' in declaration of `_mysql_Warning' _mysql.c:60: warning: data definition has no type or storage class _mysql.c:61: error: parse error before '*' token _mysql.c:61: warning: type defaults to `int' in declaration of `_mysql_Error' _mysql.c:61: warning: data definition has no type or storage class _mysql.c:62: error: parse error before '*' token _mysql.c:62: warning: type defaults to `int' in declaration of `_mysql_DatabaseError' _mysql.c:62: warning: data definition has no type or storage class _mysql.c:63: error: parse error before '*' token *** Shortened for Brevity **** _mysql.c:2685: warning: implicit declaration of function `PyImport_ImportModule' _mysql.c:2722: warning: assignment makes pointer from integer without a cast _mysql.c:2726: warning: implicit declaration of function `PyErr_Occurred' _mysql.c:2727: error: `PyExc_ImportError' undeclared (first use in this function) _mysql.c:2729: warning: `return' with no value, in function returning non-void _mysql.c: At top level: _mysql.c:1882: warning: `_mysql_ConnectionObject_dealloc' defined but not used _mysql.c:1957: warning: `_mysql_ResultObject_dealloc' defined but not used _mysql.c:2334: warning: `_mysql_ConnectionObject_setattr' defined but not used _mysql.c:2359: warning: `_mysql_ResultObject_setattr' defined but not used error: command 'gcc' failed with exit status 1 Since I'm pretty new to python and I'm not a C programmer, I was thinking that I'm missing some sort of header files either with Python or with MySQL Thanks, Jason Vance Jason S. Vance Blue Boutique Online, Llc 1715 W. Wendover Blvd. West Wendover, NV 89883 775-664-2771 801-381-4673 - Cell

2 1

Can I use tktable with MacPython?
by Thomas Green Feb. 15, 2005

Feb. 15, 2005

Hi, can anyone give me advice about how to import and use tktable in Python? I've used it successfully in tcl but when I tried "import tktable" in Python I got "ImportError: No module named tktable" (and likewise for other combinations of upper and lowercase). A small working example would be ace! (BTW I'm not really competent enough to start recompiling the source or anything like that) Thanks, Thomas Green 27 Allerton Park, Leeds LS7 4ND +44-(0)-113-226-6687 http://homepage.ntlworld.com/greenery/

2 1

Re: [Pythonmac-SIG] Mac User Python Newbies
by Jon Schull Feb. 15, 2005

Feb. 15, 2005

> Open source developers work on whatever they want or need to work on, > so the particular problems you have will get solved when someone with > the time, skill, and motivation to do so decides to scratch that itch. > If you want to speed this process along, you have a few options: > > - Persuade a suitable developer to work on the problem areas you have > (usually with money or a job) > - Fix the problems you have yourself (hey, at least you CAN) > - Deal with it as-is > > .. beggars can't be choosers :) > > -bob [ comment in the context of distribution packages but it applies > to the discussion of IDE chaos as well]. My comment: (1) In this business, beggars do choose, and they vote with their feet. If a beginner-friendly IDE is not an interesting problem for cognoscenti, the python foundation (or some such) should step in, or the python community should consider the possibility that the demographics of the development community is in danger of ceding the next generation... On Feb 13, 2005, at 6:00 AM, pythonmac-sig-request(a)python.org wrote: > Send Pythonmac-SIG mailing list submissions to > pythonmac-sig(a)python.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.python.org/mailman/listinfo/pythonmac-sig > or, via email, send a message with subject or body 'help' to > pythonmac-sig-request(a)python.org > > You can reach the person managing the list at > pythonmac-sig-owner(a)python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Pythonmac-SIG digest..." > Today's Topics: > > 1. appscript (Michael Terry) > 2. Re: Zope py2app, some progress (Bob Ippolito) > 3. Re: Mac User Python Newbies (Bob Ippolito) > 4. Re: appscript (Jacob Kaplan-Moss) > 5. Re: Mac User Python Newbies (Robert Kern) > > From: Michael Terry <michael.terry(a)mac.com> > Date: February 12, 2005 12:02:08 PM EST > To: pythonmac-sig(a)python.org > Subject: [Pythonmac-SIG] appscript > > > Hi, > > I installed the appscript module. Can someone explain to me why the > following script: > > #!/usr/bin/pythonw > > from appscript import * > > peopleRef = app('Address Book.app').people.filter(its.emails != []) > print zip(peopleRef.name.get(), peopleRef.emails.value.get()) > > ... errors with: > > from: can't read /var/mail/appscript > > ... when one from the command line? > > Thanks, > Mike > > > From: Bob Ippolito <bob(a)redivi.com> > Date: February 12, 2005 1:00:00 PM EST > To: "Roger Binns" <rogerb(a)rogerbinns.com> > Cc: Pythonmac-SIG(a)python.org > Subject: Re: [Pythonmac-SIG] Zope py2app, some progress > > > > On Feb 11, 2005, at 12:26 PM, Roger Binns wrote: > >>>> All the example code is in Objective C. Quite simply there is >>>> far too steep a learning curve to get through these layers be >>>> it Objective C or pseudo objects in C plus mapping into Python >>>> land. >>> Uh, no it isn't. A fair share of the IOKit examples are pure C or >>> C++. >> >> Ok, more accurately the examples that were looking at hierarchies >> are in Objective C. And I'm sure that working with IOKit, in C or >> Objective C, once you have done it a few times is quick and easy. If >> you haven't then a time investment is needed to understand the docs, >> the examples, the types, actually write code that works, map it into >> Python etc. > > There's a command-line application called ioreg that prints the > hierarchy. It is written in C, so it's only using IOKit, > CoreFoundation, and POSIX: > > http://www.opensource.apple.com/darwinsource/10.3.8/IOKitTools-38/ > ioreg.tproj/ > > -bob > > > > > > From: Bob Ippolito <bob(a)redivi.com> > Date: February 12, 2005 7:04:03 PM EST > To: Louis Pecora <pecora(a)anvil.nrl.navy.mil> > Cc: PythonMac <pythonmac-sig(a)python.org> > Subject: Re: [Pythonmac-SIG] Mac User Python Newbies > > > > On Feb 12, 2005, at 6:25 PM, Louis Pecora wrote: > >> Bob Ippolito wrote: >> >>>> I really like the ability to edit and just hit cmd-R to run the >>>> script. >>>> The IDE could use some updating and wart removal. Syntax coloring, >>>> better scrolling (that's damaged right now), use of scroll wheel >>>> (if present), a few other interface changes. >>>> >>>> In the end it's my tool. >>>> I don't really understand how your are doing the development. You >>>> have to jump to a term window to run the script? >>> >>> >>> The source code for the old MacPython IDE is extremely ancient and >>> nobody has expressed interest in updating it... >> >> Bob, Yeah I can see that, although for us non-guru python types who >> just want a nice language to use it still is very nice. Sad that no >> one will update it, but I realize all this stuff is on a volunteer >> basis. > > In this particular case, fixing the MacPython IDE to use the newer > Carbon conventions and facilities would more or less be a rewrite > anyway, so people have expressed interest in writing an equivalent > using Cocoa. One such effort is PyOXIDE, though it would be nice if > more of it was written in Python. > > I've personally been working on software that would be extremely > useful in the context of an IDE, such as an out-of-process GUI Python > interpreter, loading code into remote processes, creating applications > and plugins (py2app), determining dependencies (macholib/modulegraph), > PyObjC, etc. but I'm not currently working on creating or directly > improving any IDE because frankly, I'm generally more interested in > the low level stuff and an IDE wouldn't really be all that useful to > me most of the time. > >> Having said that I will lament what someone else on this list >> recently said about python (he's new to the lingo and wants to use >> python stuff), namely, everything seems scattered and now more so >> that the IDE is decaying. What to replace it with? > > It'll be replaced when a suitable replacement exists. It's not yet > clear what that replacement is, or when this will happen. > >> I know there are "solutions" since plenty of you are getting stuff >> done in Python. However, for people like me the need to separately >> install several packages just to get another one going is daunting, >> especially since the dependencies are hard to decipher. I am not >> complaining that the developers don't try to enlighten us, but since >> the development is only loosely coordinated a sense of fragility >> exists (at least for me) for any group of installed packages that >> have to work together. > > It's absolutely true that it can currently be difficult to get a suite > of packages installed if you don't already know what you're doing. > > That's part of the reason why I wrote bdist_mpkg. All it takes is one > person to build a package and package it up, and then anyone else can > just install it with a download and a few clicks. The process of > creating a package with bdist_mpkg is as easy as the usual "sudo > python setup.py install". Honestly, all you have to do (py2app svn) > is type "bdist_mpkg --zipdist --open" in the same directory as > setup.py and it will build the package, create a zip file of the > package for redistribution, and open up the package with the Installer > GUI. If you just want to install it, you can just type "bdist_mpkg" > which will do the same, minus the creation of the zip file. > > Detection of or downloading dependencies for packages are not solved > by this, largely because there IS NO STANDARD for declaring them (not > even a de-facto one, though there is ongoing work in this area), so it > is the "maintainers" job to do it by hand. However, it would be > entirely possible to build an "Enthought Python" type distribution for > Mac OS X using these facilities as-is. At least one person is > interested in creating such a distribution > <http://www.scipy.org/wikis/featurerequests/MacEnthon>, but it's not > ready yet as far as I know. I am hosting several packages built using > this system <http://undefined.org/python/packages.html> and that list > will grow whenever I have the need or when someone else packages > something and contributes it. I do, of course, reserve the right to > stop maintaining this whenever I no longer have the time or interest > to do so. > > Eventually a better system will exist, whether that's some combination > of PackageManger and bdist_mpkg, or something else like Python Eggs > <http://peak.telecommunity.com/DevCenter/PythonEggs>. Unfortunately, > for the most part, the people that are currently working on these > systems don't really have an immediate need for them, so it's not an > area of rapid development. > >> Where I'm going with this is that I am torn between my love for the >> Python language (the best I've ever used) and my needs to get work >> done (I do numerical work in my scientific research) without spending >> a lot of time and energy maintaining the software environment. >> I'm not sure how to cure this. If there is a cure. It may be >> endemic to open source. I sense that for developers its just part of >> the job and maybe even enjoyable while for potential users like me it >> is a sad frustration. >> >> Just a view from the users' side. Thanks for letting me vent. > > Open source developers work on whatever they want or need to work on, > so the particular problems you have will get solved when someone with > the time, skill, and motivation to do so decides to scratch that itch. > If you want to speed this process along, you have a few options: > > - Persuade a suitable developer to work on the problem areas you have > (usually with money or a job) > - Fix the problems you have yourself (hey, at least you CAN) > - Deal with it as-is > > .. beggars can't be choosers :) > > -bob > > > > > > From: Jacob Kaplan-Moss <jacob(a)jacobian.org> > Date: February 12, 2005 7:04:52 PM EST > To: pythonmac-sig(a)python.org > Cc: Subject: Re: [Pythonmac-SIG] appscript > > > On Feb 12, 2005, at 11:02 AM, Michael Terry wrote: >> I installed the appscript module. Can someone explain to me why the >> following script: >> >> #!/usr/bin/pythonw > > Michael -- > > It's because pythonw is a script itself; bash doesn't like #! lines to > use other scripts. It's easily enough fixed, though; just use: > > #!/usr/bin/env pythonw > > and you should be fine. > > Jacob > > > > > > From: Robert Kern <rkern(a)ucsd.edu> > Date: February 13, 2005 5:30:58 AM EST > To: pythonmac-sig(a)python.org > Subject: Re: [Pythonmac-SIG] Mac User Python Newbies > > > Bob Ippolito wrote: >> However, it would be entirely possible to build an "Enthought Python" >> type distribution for Mac OS X using these facilities as-is. At >> least one person is interested in creating such a distribution >> <http://www.scipy.org/wikis/featurerequests/MacEnthon>, but it's not >> ready yet as far as I know. > > All the packages in the main list build and install cleanly. Now I'm > working on packaging up the documentation for each package, and > unfortunately, Real Life annoyances are taking up too much time. Maybe > next week there will be a beta release. > > -- > Robert Kern > rkern(a)ucsd.edu > > "In the fields of hell where the grass grows high > Are the graves of dreams allowed to die." > -- Richard Harter > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon Schull, Ph.D. Associate Professor Information Technology Rochester Institute of Technology 102 Lomb Memorial Drive Rochester, New York 14623 schull(a)digitalgoods.com 585-738-6696

12 24

Re: [Pythonmac-SIG] Mac User Python Newbies
by has Feb. 14, 2005

Feb. 14, 2005

Bob Ippolito wrote: > > MS builds software that way cos they like to get their users locked into > > a perpetual upgrade cycle from which they can make money, but what's > > OSS's excuse? > >Maybe because in many cases, the users are the developers and adding >those 20%s together makes for some big ugly mess. I'm not sure that qualifies as an excuse; more making their bed and lying in it. :) > > Furthermore, those users aren't locked into a single fixed solution > > for, say, building GUIs: as long as wxPython, PythonCard, etc. provide > > compatible components they can plug in whichever one they want. > >Personally, I hope that developers See The Light and do interface >building in a separate but integrated application like Xcode and >Interface Builder. Exactly. Or separate, integrateable components that plug into a common base framework. That was the idea behind OpenDoc, for example: the user's work is more important than the tools, so make it the center of attention by using a document-oriented model instead of an application-oriented one. Either way though the technical goal is exactly the same: keep the coupling between components as loose as possible. That's the _key_ to getting the design right: decoupling each functional area from the others. The rest is just finding the slickest, most convenient presentation. Unfortunately, I think most folk are only thinking about the presentation when they 'design' their system, and so they miss this. They get the form looking almost right superficially, but they don't get the substance. And then they wonder why they can't get the form any better, and why it starts falling apart when they try to take it any further. > > Python's myriad web frameworks are in exactly the same situation, btw > >I think WSGI (pep 333) is a good step to fixing this problem. If you >target WSGI, at least you can shoehorn your app into a giant framework >when you need one. If I understand it correctly, WSGI decouples the app framework from the web server, which is a good thing in itself. It doesn't do anything to address the pathological kitchen sink-ism within the rest of the web-app framework, however. I think you'd need a chainsaw for that. > > I've never understood what the obsession with building every > > conceivable feature into the application core, > >I think this is largely caused by complexity of the alternative and the >convenience of doing it in this way. Developer convenience up to a point, yes. It requires less up-front planning and major direction changes: just jump in and write some code. Yet the same could be said for procedural vs OO construction, so why are developers seeing the advantages of modular design in the small but still missing it so often in the large? >The problem with the Unix model is that processes only know how to >exchange raw data (sockets, pipes, files). In lots of cases you want >to exchange a higher level representation of information, and there >aren't a whole lot of easy ways to do that. But there are ways. OpenDoc was built upon Apple events, for example. And assuming you only have Python talking to Python then you don't even need something that complex. It's not like there isn't prior art to study and take ideas from. >I'm pretty sure that these >large frameworks suffer from the same problem. It's much easier to >exchange high level representations of data with yourself than it is to >exchange them with someone else.. It's interesting that even MS are now moving away from the DCOM approach and towards an Apple event/Apple Event Object Model approach. I think Apple were definitely onto something with these: it's all about where you make the split, and finding the right point makes the difference between moving Mohammed or moving the mountain. >that, and it's much easier to design >something ad-hoc if you don't concern yourself with keeping things >modular. Of course. I often start out that way myself; it's hard to know what kind of high-level structure you're going to need if it's your first time exploring this particular problem. The trouble sets in when an initially ad-hoc design doesn't bother to improve its internal organisation as it grows; if you don't keep that burgeoning complexity under control then sooner or later the whole thing degenerates into a big ball of mud. It's a great very-short-term strategy, but an ultimately counter-productive stinker if you're planning to be in for the long haul and fail to replace it ASAP. And it seems that very often programmers never do get around to that 'rebuild and replace' stage, because as soon as they've reached working code it's considered 'done', and to then throw that code away and start all over again is anathema. Coming from a fine art background, I _know_ that if you've a day to draw a life picture, then the best way to spend that time is 'wasting' the first half on throwaway sketches and only sitting down to the final version in the final few remaining hours, not spend all day hammering away at this one single drawing from 9 till 5. You mention py2app, but must realise yourself that py2app's potential for growth and improvement is itself ultimately constrained by the framework you've built it in, i.e. distutils. And, conversely, distutils' room for improvement is severely constrained by the need not to rock the boat for those that have already built upon it. The longer code is left to harden, the harder it will be to do anything to change it later, so best spend as much energy as you can as early on as possible to ensure that when it does set, it's not in a form you're going to regret years from now. (Unless you're the perverse sort that actively enjoys doing heroic total rewrites for the rest of your life...:p) IDEs are exactly the sort of problem that's crying out for exactly this sort of hard, hard tearing down and rebuilding approach because right throughout their lives there's going to be this strong requirement to add new features, specialist tools, remove obsoleted tools, replace, extend, rebuild, etc. One really good, extensible IDE application framework and we might not be in this foolish situation where there's a dozen all "nearly done" IDEs, all with a huge amount of overlapping functionality, which means duplication of effort; i.e. a waste of time and energy. Folk seem to acknowledge there's a constant underlying problem at work, so why don't they spend more time trying to put that right instead of reinventing the same old mistakes as before? It should be a wonderfully rich and tasty problem for those that fancy the exercise, and I'm sure there's folk that would; maybe not as instantly glamorous as "oh look I just made a yet-another-editor", but no passing flash in the pan either if/when they manage to pull it off. Cheers, has -- http://freespace.virgin.net/hamish.sanderson/

2 3

Re: Macu User Python Newbiew
by Brendan Simons Feb. 14, 2005

Feb. 14, 2005

" cmd [ " moves a block of selected text one tab level back (4 spaces if you've set "auto-expand tabs"). and " cmd ] " moves a block of text one level forward. Is this what you're looking for? TextWrangler is no IDE, but as a code editor it's very good. -Brendan On 14-Feb-05, at 2:03 PM, pythonmac-sig-request(a)python.org wrote: > But does it do Python indenting correctly? This is my only really > obstacle with BBedit (a couple versions old). You can make it put in > spaces instead of tabs, but once they're in they are treated only as > spaces, rather than levels of indentation, so when you want to remove > a level you have to hit delete four times. Not horrible, but annoying.

1 0

New wiki entry
by Robert White Feb. 14, 2005

Feb. 14, 2005

I just added a new wiki entry, "Describe Apple's Framework implementation of Python and how that affects me adding new Python implementations". Please review it. If it does not answer your questions about Apple's Framework installation, please send those questions to this list or me personally and I will try to adjust the entry to answer the question. Thanks, Bob White

1 0