Mailman 3 June 2004 - Pythonmac-SIG

Re: [Pythonmac-SIG] Python for OSX programming beginner?
by Russell E Owen March 20, 2005

March 20, 2005

>Been lurking here for a while and quietly observing. > >I am looking for a programming language and preferably and IDE for a >young nephew wanting to dip his toes in the programming pool... >Is Python worth further investigating and how good are the IDEs? >Is there something along the lines of REALbasic VisualBasic >integrated interface/code style IDE available? >What are the specialities limits of the language? >Why learn Python rather than battle on and master C or more >particularly Objective C ? >Rather difficult to answer, but how different is the learning curve? > >Many thanks for any help. Hmmm...I suggest the following: Smalltalk: Squeak and VisualWorks NC are both free (the latter only for noncommercial use). Smalltalk is a lovely, simple really powerful language that includes: - powerful IDE and class browser with integrated debugger; smalltalk has the best development environment I've ever seen for a language because it includes live debugging, live changing of classes (want to fix a method? go ahead; the change propagates; fix it and continue on the fly) - really simple yet powerful language; one of the most elegant languges I've seen, though the syntax is a bit different than C and Python programmers are used to - very rich class library, including one of the nicest collection classes (lists, sets, etc.) available Between these two, squeak is smaller and more fun and includes a nifty GUI called Morphic; however it all runs in one big window (very non-Mac like). VisualWorks is more Mac-like (at least on a Mac) and more mature, but is much larger. Both are fully cross-platform (write once, run everywhere). One limitation to smalltalk is that it's not much good for simple scripting, hence simple text processing scripts and such. Python really shines there, so... Python. This is a really nice language and he'll be able to go far with it. However, based on what you said above, some of its limitations make me nervous: - there is no really well integrated GUI, unlike the suggestions above. You can do GUI programming, but you have to choose a 3rd party package and they are fully powerful, but the two main ones (Tkinter and wxPython) are somewhat clumsy and poorly documented. - hence there is no really first rate IDE (not to put down the IDEs that are there, but in comparison to smalltalk or RealBasic...) Note: python is built into MacOS X 10.2, but it's an outdated version missing some of the things that make the language sane (such as readlines support and a GUI package). Install the missing items or a better package (if you've been reading you've seen various options for that including at least one recent binary installer). I suggest learning those two (since their few weaknesses are complimentary), but you could also consider: Buy RealBasic. The knowledge is well worth the money! It's not a wonderful language, but not so bad either and if he already knows it, well...that's a huge leg up. Java. Not sure what the IDE situation is for MacOS X, but the language is reasonable (much saner than C++). The problem is that the need to declare the type of all objects makes it a clumsy and messy language compared to Python and Smalltalk. I suggest NOT using C++. The language is too arcane and messy. The object model is insanely complicated and the pitfalls fill volumes. Learn to program first, then learn C++ later if you really have to. -- Russell

3 3

(no subject)
by Keith Nemitz Dec. 6, 2004

Dec. 6, 2004

>> >> >> huh? I mean does everyone use[-3:] instead and 0 is taboo? I'm used >> to the Icon programming language where "food"[-3:0] returns --> ood > > "food"[-3:] is equivalent to "food"[-3:None] (that is, literally, how > it works out internally) > > "food"[-3:0] is just backwards :) If anything, it should give you > "oof", but that's too confusing. > > -bob > Thank you. I knew there had to be a reason. If you think about lists as ring buffers, however, then "food"[-3:0]-->"ood" makes plenty of sense and can be very useful. My case that started this whole thread had to do with iterating from negative to positive, returning larger substrings on each iteration. It broke with the zero index. So I had to special case it. sigh, I wonder if adding this 'concept' to python (indexing lists as ring buffers) would break any existing code... Heck while I'm at it, changing the language, might as well add nested comments, and (my personal favorite) record names, implemented like this: record <tuple of enums> tuple of enums ::= (<enum> [,enum]*) enum ::= <string>[= <int>] ...such that the keyword 'record' turns the strings into module and/or class scoped indexes. Isn't it fun to dream? Keith Nemitz

11 28

WebKit, SVG
by Dinu Gherman Oct. 4, 2004

Oct. 4, 2004

Hi, recently I played a bit with Konfabulator, some kind of a "widget framework" for OS X, which looks very nice at the beginning. But after a while it seemed to me that despite the very good idea, its implementation is kind of using the wrong technology. They try to make it very simple to define widgets by specifying them in XML and adding behaviour in Javascript code. This is done in some very strange way, though, like putting the Javascript code insinde XML comments, which is the recommended way of doing it! Well, I think SVG and Python would be the better combination, so I wonder if Apple's WebKit is any good in making use of Adobe's SVG renderer plug-in, somehow? Of course, then we'd still need some bridge to Python, but you need to start somewhere... Dinu PS: www.konfabulator.com -- Dinu C. Gherman ...................................................................... "The thing that impresses me the most about America is the way parents obey their children." (King Edward VIII)

7 9

Quicktime, versions, 3GPP
by Dinu Gherman Aug. 15, 2004

Aug. 15, 2004

Hi again, does anybody know if the Quicktime modules under Carbon do always support the currently installed/found version of Quicktime during compile time, or is it a more difficult story? I'm especially interested in Quicktime 6.3 and higher with their ability to save in 3GPP mode for mobile devices... Thanks, Dinu -- Dinu C. Gherman - http://python.net/~gherman ...................................................................... "The best way to predict the future is to invent it." (Alan Kay)

3 4

Some thoughts on Python and OS X
by Kenneth McDonald July 29, 2004

July 29, 2004

The following comes from some experiences I've had recently whilst wrangling with wxPython/SPE, plus some others encountered in the past while doing custom installs of Tk and tkinter. I don't want to start any flame wars, and I certainly don't want to hurt any feelings--the Python people at Apple are doing a great job, and I really appreciate their effort. However, the "Apple Philosophy" as applied to Python (and indeed as applied to much of the UNIX subsurface in OS X) is making things painfully, and in my opinion unnecessarily, difficult to use. First, the obvious: Having a "required, custom" build of Python on OS X is a Bad Idea. Last I heard, this was the official OS X way of doing things, i.e. the Python you got was what you should use, don't try replacing it, and no, it's not a stock Python. I believe this has been recognized to be a problem and is being worked on--sorry if I'm ignorant of recent fixes, I "threw out" the stock OS X Python some time ago, as I needed my own custom compilations. In general (and I'm sure the Apple techs understand this, but perhaps you could pass this on to those in management who don't?), DON'T EVER take a community standard tool such as Python and "improve" it in such a manner as to make it incompatible with what people have come to expect. If you must produce an Apple-specific version which requires special consideration when being used with other packages, then observe the following: 1) The _standard_ version should be the standard; even on OS X. People who want to use Python without caring about the OS its on will then be able to use it properly. Those who want to make use of the os-enhanced version will know what to do. 2) Make sure that an 'enhanced' version can coexist peacefully with the standard version. One of the things that is expected is that I can download, compile, and install a more recent version of Python without problem (assuming the newer version itself doesn't have problems.) Another is that add-ons for Python which have been written to install nicely in a generic UNIX environment should continue to do so under OS X. Next, paths. I can understand why Apple (actually, probably NeXT) decided to come up with improvements on the UNIX file structure. But why, oh why, couldn't they have maintained some sort of backward compatibility using links? I've effectively recreated my own UNIX file structure using links, to make up for this, and would be surprised if others haven't as well. In particular, why the heck isn't there the equivalent of /usr/local? Having this basic de facto standard sort of file structure in place would save us UNIX software users countless hours in headaches. Yes, it's easy to argue that the problems are the fault of bad installation scripts and makefiles. Well, yes, in theory that's probably true; but so what? The point of software is to be a useful tool, not to drive the customer crazy by insisting that somebody else, in assuming a de facto standard of the time would continue into the future, made a mistake. I find this a particular problem when it comes to Frameworks and Libraries. Here's a typical example of installing a couple of Python modules recently: 1) Compile module A--works, great. Install it. Where the heck are the files? Do a search on the disk. Ah, there they are in /Library/Frameworks/Python/.../.../... and so on .../2.3/site-packages. Create a link from a more reasonable location so they'll be on the python path. 2) Compile and install module B. Where is it? Disk search. Ah, it's in /Library/Python/2.3. Create link. Why did it end up here, vs. Module A in Frameworks? Beats me. And why, for that matter, are all of these modules always ending up in a '2.3' directory? I happen to know that some of them aren't dependent on the Python binary, and it looks to me as if, when 2.3 changes to 2.4, I'm gonna have some unnecessary work, again. Trust me, if a module is incompatible with 2.4, I'll know it soon enough; you don't have to force me to move everything manually to the 2.4 path. None of this is going to make me move off of OS X, of course; it still is, by far, the best OS for most users IMHO, myself included. But this situation will cost Apple some money; I generally keep fairly up-to-date with hardware, and was planning on getting a new Powerbook when they hit 2 GHz. However, I've had to do so much manual tweaking to my system that the effort needed to recreate that on a new drive is a little too much to want to repeat in the forseeable future, so Apple's probably going to have to hit 3GHz for me to decide it's worth the pain. (Yes, I know I don't have to do a "clean" install of everything when I go to a new system, but that's one of the things I do to help me clean all the cruft out.) I'm looking forward to what comes out in the future, I have a lot of confidence in the Python people at Apple, and I have no problems at all in continuing to pay for new versions of OS X which bring new features and improvements. I just hope that the above is of some help in deciding how some of those features should be implemented in the future. Thanks, Ken McDonald

10 15

framework _only_ build fails on 10.1
by Pascal Oberndoerfer July 4, 2004

July 4, 2004

I doubt this is of great interest anymore but still: maybe I just missed something? I tried to build the framework _only_ on 10.1 yesterday. No frameworkinstallapps or frameworkinstallextras. During make I get this problem: cc -Wl,-F. -bundle -framework Python build/temp.darwin-5.5-Power_Macintosh-2.3/macosmodule.o -L/Library/Frameworks/Python.framework/Versions/2.3/lib -L/usr/local/lib -o build/lib.darwin-5.5-Power_Macintosh-2.3/MacOS.so -framework Carbon /usr/bin/ld: Undefined symbols: _CGMainDisplayID This is related to macosmodule.c I guess. Obviously this leads to unexpected skips during make test: 3 skips unexpected on darwin: test_macostools test_aepack test_scriptpackages and make frameworkinstallframework fails too of course: ./python.exe ./Mac/scripts/cachersrc.py -v /Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/plat-mac /Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools Traceback (most recent call last): File "./Mac/scripts/cachersrc.py", line 7, in ? import macresource File "/Users/pob/Desktop/Python-2.3.3/Lib/plat-mac/macresource.py", line 6, in ? import MacOS ImportError: No module named MacOS make[1]: *** [installmacsubtree] Fehler 1 make: *** [frameworkinstallmaclib] Fehler 2 These were the steps taken: - download waste-21b1.sit to Desktop - download Python-2.3.3.tgz to Desktop - unpack both to Desktop - rename 'WASTE 2.1b1 Distribution' to waste - open Terminal - cd to ~/Desktop/Python-2.3.3 - ln -s ../waste waste - ./configure --enable-framework - edit ~/Desktop/Python-2.3.3/Mac/OSX/make for 10.1/10.2 on lines 13-16 (PBXBUILD=pbxbuild) (Don't know if this is necessary when not installing extras/apps) - make - make test - make frameworkinstallframework Thanks, Pascal

3 2

Tiger info, anyone?
by Robert Brown June 30, 2004

June 30, 2004

I guess I'm not supposed to say what's built into Tiger, but I will mention that the 2.3.2 version I compiled and we're standardized with in the lab at the moment works fine in Tiger even though it was compiled in Panther. VTK needs a rebuild, as usual though. --------------------------------------------------- Robb Brown Seaman Family MR Research Centre Calgary, Alberta, Canada

3 3

Re. [Pythonmac-SIG] talkingpanda installer - PyObjC experience
by has June 30, 2004

June 30, 2004

Bob wrote: > I'm also thinking that I should put some more work into aeve, >because it's much better suited for *receiving* and *sending* apple >events than appscript is Yeah, appscript's basically been a one-trick pony to-date, and while it's very application scripter-friendly it's a bit of a non-starter as far as application developers are concerned. I've been aware of this problem for a while and have started breaking it up to allow other kinds of use. Early days, so nothing's close to working yet (there's a lot of dependencies to pull apart, new APIs to create, etc.), but here's an idea of what I'm doing: - The Python/AE type converters and AE dispatch code have moved to a new package, AEM. I've already started work on this. This should provide a basic interface for AE communication without being tied to application terminology resources. - Specifier construction and ApplicationTerminology will also be spun off into individual concerns. - Specifier construction needs to take a two-tier approach: the current, terminology-guided, validating, syntactically-sugared interface, and a slightly lower-level API for constructing complex specifiers using AE codes only which will probably end up in AEM. - 'appscript' itself will end up as 'just another' client to these services; in its case providing a high-level, AppleScript-like application scripting interface just as it currently does. (It'll get all the terminology-based specifier stuff.) So it should continue to work and feel much as it already does, but will no longer be the only way to do AEs. - I've not looked at AE receiving or asynchronous use yet, but should get round to it eventually. BTW, one of the reasons for putting lots of input-checking into Specifiers is that it'll make a nice system for handling incoming Apple events, able to do a lot of user input validation and intelligent error reporting (unlike Cocoa Scripting, which is atrocious for this sort of thing). The ultimate goal, of course, being to create a complete Python Scripting framework (like appscript, this is something I'll eventually need myself for another project I'm working on), although that is still a looong way off. I expect this work to take some months; I'll probably release 0.6.0 in the interim (I've knocked out a few bugs and tidied some code, and working with Ryan Wilcox to add remote scripting support). As always, I'm open to suggestions, requests, assistance, etc. HTH has -- http://freespace.virgin.net/hamish.sanderson/

2 2

Tiger info, anyone?
by Eric Nieuwland June 29, 2004

June 29, 2004

Hi all, Just to be curious: is ther any news on the Python version etc. in Tiger? --eric

2 1

Problem Running PythonIDE
by marmille June 29, 2004

June 29, 2004

I have MacPython 2.3.3 installed on OS X 10.2.8. I've modified my login so that /usr/local/bin is the first folder on my PATH. I can run python from Terminal just fine, but when I try to start the PythonIDE app by double-clicking on it, all I see is the splash screen for a second then it quits -- and no error messages or dialogs are displayed. Since I don't have a clue what it's unhappy about, I was wondering if anyone had any suggestions. TIA, -Martin

2 4