Mailman 3 December 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

ANN: Python 2.3->2.4 "compatibility" package
by Bob Ippolito Feb. 2, 2005

Feb. 2, 2005

I've put together a quick set of packages that brings a few new/updated modules from Python 2.4 to Python 2.3: Cross-platform: new subprocess module new decimal module For Mac OS X: new LaunchServices wrapper new OSA wrapper updated QuickTime package A binary installer built with bdist_mpkg is available from: http://undefined.org/python/Python23Compat.zip Sources are available by svn at: http://svn.red-bean.com/bob/Python23Compat/trunk/ The installer can be built as follows (assuming py2app trunk installed): % python setup.py bdist_mpkg or % bdist_mpkg -- (the -- makes sure it doesn't open up N installers.. bdist_mpkg by default automatically opens the new package) -bob

1 1

Testers needed again: Fix installer 1.2
by Jack Jansen Jan. 13, 2005

Jan. 13, 2005

There's yet another new version of the Python 2.3 fix installer available: <http://www.cwi.nl/~jack/macpython/JaguarPythonFix.dmg>. This one should also make C++ extensions build correctly again with apple-installed Python 2.3 on 10.3, after installing a later framework build. Please let me know whether it works, especially with real C++ extensions (I only tried a toy extension). And, for the record, I used Ronalds solution of using driver scripts for gcc and g++ that set the MACOSX_DEPLOYMENT_TARGET environment variable before running the compiler. -- Jack Jansen, <Jack.Jansen(a)cwi.nl>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman

4 5

ANN: pyobjc-1.2
by Ronald Oussoren Jan. 2, 2005

Jan. 2, 2005

PyObjC 1.2 is now available for download at http://pyobjc.sourceforge.net/ PyObjC is a bridge between Python and Objective-C. It allows full featured Cocoa applications to be written in pure Python. It is also easy to use other frameworks containing Objective-C class libraries from Python and to mix in Objective-C, C and C++ source. Python is a highly dynamic programming language with a shallow learning curve. It combines remarkable power with very clear syntax. The installer package includes a number of Xcode templates for easily creating new Cocoa-Python projects. PyObjC also supports full introspection of Objective-C classes and direct invocation of Objective-C APIs from the interactive interpreter. PyObjC requires Mac OS X 10.2 or later and Python 2.3 or later. PyObjC works both with the Apple provided Python installation in Mac OS X 10.3 (and later) and with MacPython 2.3. This release features several bugfixes, improved documentation as well as support for categories, easier customization and basic support for creating Interface Builder palettes. See the news file at http://pyobjc.sourceforge.net/NEWS-1.2.txt for more information. PyObjC is released with an open source license (MIT style).

3 7

How badly is _locale broken?
by Brett C. Dec. 31, 2004

Dec. 31, 2004

I am planning to attempt to fix the _locale module (which 'locale' itself imports and uses) for OS X. As of this exact moment I am planning just fixing localeconv (thanks to CFNumberFormatter and setlocale still at least storing the supposed locale, even if it does ignore it), but I realized other stuff might be broken. Since I never personally use the module, does anyone know the extent of the breakage? Obviously I would rather just have to fix localeconv and keep my life simple, but if it is more extensive I can see what I can do. -Brett

6 9

ANN: py2app 0.1.7
by Bob Ippolito Dec. 31, 2004

Dec. 31, 2004

This announcement is available in HTML at: http://bob.pythonmac.org/archives/2004/12/30/ann-py2app-017/ `py2app`_ is the bundlebuilder replacement we've all been waiting for. It is implemented as a distutils command, similar to `py2exe`_, that builds Mac OS X applications from Python scripts, extensions, and related data files. It tries very hard to include all dependencies it can find so that your application can be distributed standalone, as Mac OS X applications should be. `py2app`_ 0.1.7 is included in the installer for `PyObjC`_ 1.2. If you have installed `PyObjC`_ 1.2, then you already have `py2app`_ 0.1.7 installed. Download and related links are here: http://undefined.org/python/#py2app `py2app`_ 0.1.7 is a bug fix release: * The ``bdist_mpkg`` script will now set up sys.path properly, for setup scripts that require local imports. * ``bdist_mpkg`` will now correctly accept ``ReadMe``, ``License``, ``Welcome``, and ``background`` files by parameter. * ``bdist_mpkg`` can now display a custom background again (0.1.6 broke this). * ``bdist_mpkg`` now accepts a ``build-base=`` argument, to put build files in an alternate location. * ``py2app`` will now accept main scripts with a ``.pyw`` extension. * ``py2app``'s not_stdlib_filter will now ignore a ``site-python`` directory as well as ``site-packages``. * ``py2app``'s plugin bundle template no longer displays GUI dialogs by default, but still links to ``AppKit``. * ``py2app`` now ensures that the directory of the main script is now added to ``sys.path`` when scanning modules. * The ``py2app`` build command has been refactored such that it would be easier to change its behavior by subclassing. * ``py2app`` alias bundles can now cope with editors that do atomic saves (write new file, swap names with existing file). * ``macholib`` now has minimal support for fat binaries. It still assumes big endian and will not make any changes to a little endian header. * Add a warning message when using the ``install`` command rather than installing from a package. * New ``simple/structured`` example that shows how you could package an application that is organized into several folders. * New ``PyObjC/pbplugin`` Xcode Plug-In example. Since I have been slacking and the last announcement was for 0.1.4, here are the changes for the soft-launched releases 0.1.5 and 0.1.6: `py2app`_ 0.1.6 was a major feature enhancements release: * ``py2applet`` and ``bdist_mpkg`` scripts have been moved to Python modules so that the functionality can be shared with the tools. * Generic graph-related functionality from ``py2app`` was moved to ``altgraph.ObjectGraph`` and ``altgraph.GraphUtil``. * ``bdist_mpkg`` now outputs more specific plist requirements (for future compatibility). * ``py2app`` can now create plugin bundles (MH_BUNDLE) as well as executables. * New recipe for supporting extensions built with `sip`_, such as `PyQt`_. Note that due to the way that `sip`_ works, when one sip-based extension is used, *all* sip-based extensions are included in your application. In practice, this means anything provided by `Riverbank`_, I don't think anyone else uses `sip`_ (publicly). * New recipe for `PyOpenGL`_. This is very naive and simply includes the whole thing, rather than trying to monkeypatch their brain-dead version acquisition routine in ``__init__``. * Bootstrap now sets ``ARGVZERO`` and ``EXECUTABLEPATH`` environment variables, corresponding to the ``argv[0]`` and the ``_NSGetExecutablePath(...)`` that the bundle saw. This is only really useful if you need to relaunch your own application. * More correct ``dyld`` search behavior. * Refactored ``macholib`` to use ``altgraph``, can now generate `GraphViz`_ graphs and more complex analysis of dependencies can be done. * ``macholib`` was refactored to be easier to maintain, and the structure handling has been optimized a bit. * The few tests that there are were refactored in `py.test`_ style. * New `PyQt`_ example. * New `PyOpenGL`_ example. `py2app`_ 0.1.5 was a major feature enhancements release: * Added a ``bdist_mpkg`` distutils extension, for creating Installer an metapackage from any distutils script. - Includes PackageInstaller tool - bdist_mpkg script - setup.py enhancements to support bdist_mpkg functionality * Added a ``PackageInstaller`` tool, a droplet that performs the same function as the ``bdist_mpkg`` script. * Create a custom ``bdist_mpkg`` subclass for `py2app`_'s setup script. * Source package now includes `PJE`_'s `setuptools`_ extension to distutils. * Added lots of metadata to the setup script. * ``py2app.modulegraph`` is now a top-level package, ``modulegraph``. * ``py2app.find_modules`` is now ``modulegraph.find_modules``. * Should now correctly handle paths (and application names) with unicode characters in them. * New ``--strip`` option for ``py2app`` build command, strips all Mach-O files in output application bundle. * New ``--bdist-base=`` option for ``py2app`` build command, allows an alternate build directory to be specified. * New `docutils`_ recipe. * Support for non-framework Python, such as the one provided by `DarwinPorts`_. .. _`py.test`: http://codespeak.net/py/current/doc/test.html .. _`GraphViz`: http://www.pixelglow.com/graphviz/ .. _`PyOpenGL`: http://pyopengl.sf.net/ .. _`Riverbank`: http://www.riverbankcomputing.co.uk/ .. _`sip`: http://www.riverbankcomputing.co.uk/sip/index.php .. _`PyQt`: http://www.riverbankcomputing.co.uk/pyqt/index.php .. _`DarwinPorts`: http://darwinports.opendarwin.org/ .. _`docutils`: http://docutils.sf.net/ .. _`setuptools`: http://cvs.eby-sarna.com/PEAK/setuptools/ .. _`PJE`: http://dirtSimple.org/ .. _`py2app`: http://undefined.org/python/#py2app .. _`py2exe`: http://starship.python.net/crew/theller/py2exe/ .. _`PyObjC`: http://pyobjc.sf.net/

1 0

Py2App 0.1.7
by Chris Barker Dec. 31, 2004

Dec. 31, 2004

Hi all (but particularly Bob) I just installed Py2App with the installer, but when I tried to use it I got: Traceback (most recent call last): File "setup.py", line 21, in ? import py2app File "/purelib/py2app/py2app/__init__.py", line 33, in ? File "/purelib/py2app/py2app/install.py", line 15, in ? File "/purelib/py2app/py2app/command/__init__.py", line 1, in ? File "/purelib/py2app/py2app/build_app.py", line 20, in ? File "/purelib/py2app/modulegraph/find_modules.py", line 21, in ? File "/purelib/py2app/modulegraph/modulegraph.py", line 15, in ? ImportError: No module named ObjectGraph My first question was: "where the heck is /purelib ?" After some poking around, I found that indeed, there is no module objectgraph in: /Library/Python/2.3/altgraph/ which is version "0.6.1" but there is one in: /Library/Python/2.3/py2app/altgraph which is version "0.6.3" As I'd never heard of altgraph before, I'm guessing that the older version was installed by a previous version of Py2App, and Py2app now puts it in a different place, and the older one is being found first. To test this, I removed the older one, and then got: Traceback (most recent call last): File "./setup.py", line 10, in ? import py2app File "/purelib/py2app/py2app/__init__.py", line 33, in ? File "/purelib/py2app/py2app/install.py", line 15, in ? File "/purelib/py2app/py2app/command/__init__.py", line 1, in ? File "/purelib/py2app/py2app/build_app.py", line 25, in ? ImportError: No module named MachOGraph So I then deleted everything outside of /Users that had py2app in it. Then re-installed py2app. Running it again, I got the same error: ImportError: No module named MachOGraph Looking in the source, I see that MachOGraph.py is in src/macholib, but in my python installation macholib is in both /Library/Python/2.3/ and /Library/Python/2.3/py2app/ just like altgraph. lather, rinse repeat, and BINGO! it works. So, am I right that those older versions of altgraph and macholib were installed by an older Py2app? If so, some sort of waring should be put in about that. Also, while it's probably a good idea that you're now putting those packages inside the Py2app directory, it would probably be better to load them as: from Py2app.macholib import MachOGraph So that you know you're getting the version you installed for Py2app. By the way, if I needed altgraph for something else, I'd now be kind of screwed. Tome, this supports the argument I've been making for versioning. If we had a standard approach for versioning python packages, you could have the Py2app installer install the version of altgraph (and whatever else) it needs, and not screw up an exiting installation that other folk's code might be depending on. -Chris PS: Now that it works, it works fabulously! My simple wxPython app built with the very simplest of setup.py files, except for wxversion, which I'm going to go read Bob's changes in the Wiki, and figure out how to do that. Nice job. -- 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

2 3

Re: [Python-checkins] python/dist/src/Mac/OSX fixapplepython23.py, 1.1, 1.2
by Bob Ippolito Dec. 30, 2004

Dec. 30, 2004

On Dec 28, 2004, at 4:30 PM, jackjansen(a)users.sourceforge.net wrote: > Update of /cvsroot/python/python/dist/src/Mac/OSX > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv9229 > > Modified Files: > fixapplepython23.py > Log Message: > Just passing -undefined dynamic_lookup isn't enough: we also need to > set > the MACOSX_DEPLOYMENT_TARGET environment variable to 10.3 when calling > the > loader. And we do this with "env" because distutils apparently doesn't > understand environment variable assignments before command names. This is the wrong fix. Distutils is dumber than you think. This patch just breaks C++ compilation in a different way. The correct solution is a patch to distutils of some kind. from distutils/unixccompiler.py:174 if target_lang == "c++" and self.compiler_cxx: linker[0] = self.compiler_cxx[0] self.spawn(linker + ld_args) "linker" is the variable expanded LDSHARED (or whatever comes out of sysconfig.customize_compiler). -bob

4 11

wxDocsViewer
by Charles Hartman Dec. 30, 2004

Dec. 30, 2004

Somehow I seem to have broken wxDocsViewer -- the viewer program comes up but no files appear onscreen. (They seem to be stored as .zip files inside the app bundle's resources folder, but I can't open them from within wxDocsViewer.) I tried re-downloading it, but no good; apparently I did something to my system that busted it. The most recent thing I did was to load PyQt (and free Qt and SIP) -- could that have anything to do with it? Sorry to be so clueless about something presumably simple. Charles Hartman Professor of English, Poet in Residence http://cherry.conncoll.edu/cohar http://villex.blogspot.com

1 0

BuildApplet in next distro of MacPython?
by Kevin Walzer Dec. 30, 2004

Dec. 30, 2004

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm curious about whether BuildApplet and PythonIDE will be included in the next iteration of MacPython, or whether these will be replaced by py2app and PyOxide. Although I know these are old technologies, especially BuildApplet, I'd like to request that they be retained, even if they're not updated or enhanced. The reason I'm asking is that I make extensive use of BuildApplet in the packages I maintain. I've had inconsistent luck with BundleBuilder, py2app, and py2applet--mostly bad luck. The nice thing about BuildApplet that it is, in fact, very simple, even dumb, in creating applications: it saves the script in question, that's it. It then becomes a simple matter to add the additional scripts that come with an application to the app bundle in the appropriate directory, to edit the info.plist file, to change the icon, etc. In short, I have control over almost the entire process of packaging. And I've documented this process pretty thoroughly at my website. I realize there are tradeoffs with this approach. Apps I bundle with BuildApplet don't have their external dependencies included (wxPython, PyQt, whatever). But if those external dependencies are installed on the ~ user machine, then the BuildApplet process works flawlessly. py2app is a lot more elegant and smarter in what it does in terms of packaging, but it's also more complex. That is, if there's an error, it's very hard--at least for me--to debug. The build process dies. I tested this yesterday with both py2app and py2applet with Eric3, an application I have successfully with BuildApplet. With both py2app and py2applet, something didn't get included, even though Bob has now added PyQt support to py2app. Neither he nor I could figure out what the problem was. The result was that the bundle created with py2app crashed, while py2applet just died during the build process. This isn't a complaint about py2app: I've tested it with simpler applications and it works beautifully. By all means, it should be the featured method for packaging apps in MacPython. But if BuildApplet and PythonIDE can be retained, even if it's deprecated, that would be enormously helpful to me. A workable alternative would be if Glenn Andreas continued to include support for BuildApplet in PyOxide. Glenn, is this possible? Cheers, Kevin Walzer, PhD WordTech Software--Open Source Applications and Packages for OS X http://www.wordtech-software.com http://www.smallbizmac.com http://www.kevin-walzer.com mailto:sw@wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB0uIaJmdQs+6YVcoRAuqLAJ9s5DDormJMRtyH/Lp1KccYCF/cLgCeMfKO WWWCmzfcOh5KCQXq/0nZTjY= =vwbz -----END PGP SIGNATURE-----

6 11