mirror of https://github.com/python/cpython
998a40a6d4
that will detect an __main__.py or __rawmain__.py in the application bundle. This file is then exectued as the main script. We now have applets in MachO Python!!! The difference between __main__ and __rawmain__ is that the former gets a complete simulated argv (so you can drop files on the applet and the script sees them in sys.argv) while the latter skips the argv simulation and the <option>key dialog. This keeps the AppleEvent that started the app intact, as well as the funny "-psn_xxxx" argv[1] argument, so the script can do with these what it wants. |
||
---|---|---|
.. | ||
Build | ||
Compat | ||
Contrib | ||
Demo | ||
Distributions | ||
IDE scripts | ||
Include | ||
Lib | ||
MPW | ||
Modules | ||
OSX | ||
OSXResources | ||
Python | ||
Resources | ||
Tools | ||
Unsupported | ||
Wastemods | ||
mwerks | ||
scripts | ||
tclmods | ||
HISTORY | ||
ReadMe | ||
ReadMe-dev | ||
ReadMe-src | ||
Relnotes | ||
_checkversion.py |
ReadMe
How to install Python 2.2a3 on your Macintosh --------------------------------------------- This is a MacPython that can run on classic MacOS (from 8.1 onwards) and natively on MacOSX. The installer tries to work out whether you can use the Carbon version or not. You should definitely read the Relnotes file too, and the section below about toolbox module reorganization. A special note about the active installer: do not background it, it may hang your machine. This is a general problem with Vise active installers, MindVision are working on it. Aside from the general new Python 2.2a3 listed in the general relnotes file there is some other new machine-independent stuff in this release as well, as it was built from newer sources than unix/windows 2.2a3. ------ If this is your first encounter with Python: you definitely need the common user documentation (common to all platforms). You can find this (in various forms) on www.pythonlabs.com, www.python.org and ftp.python.org. Through there, or via http://www.cwi.nl/~jack/macpython.html you can also find the most recent MacPython distribution. Mac-specific documentation is included in this distribution in folder Mac:Demo. The documentation is sparse, but it will have to serve for now. The documentation is in HTML format, start with index.html. This installer installs MacPython for classic PPC MacOS, MacPython for Carbon (OS X, OS 9 or OS8 with CarbonLib installed) or both, depending on your configuration. By selecting custom install you can bypass these tests and install what you want. If you want 68k support you will have to stay with MacPython 1.5.2. Toolbox module reorganization and more -------------------------------------- You can safely skip this section if this is your first encounter with MacPython. I am working on a new organization of the mac-specific modules, and in general bringing the MacPython folder structure more in line with unix-Python. This is not only a good idea, it will also immensely facilitate moving MacPython functionality to an OSX Python that is based on Mach-O and the unix-Python distribution. But don't worry: MacPython is definitely not dead yet, and the hope is that the transition will be as seamless as possible. First a change that should not cause too much concern: :Mac:Plugins has gone, and most of the dynamically loaded modules have moved to :Lib:lib-dynload. Second, and more important: the toolbox modules, such as Res and Resource, have moved to a Carbon package. So, in stead of "import Res" you should now say "from Carbon import Res" and in stead of "from Res import *" you should use "from Carbon.Res import *". For the lifetime of MacPython 2.2 there is a folder :Mac:Lib:lib-compat on sys.path that contains modules with the old names which imports the new names after issuing a warning. Note that although the package is called Carbon the modules work fine under classic PPC, and they are normal classic modules. Also note that some modules you may think of as toolbox modules (such as Waste) really are not, and they are not in the Carbon package. Some open issues I would like to discuss on the PythonMac-SIG, please join in if you have views on the matter: - Is this all a good idea? - Some modules are not in the Carbon package (icglue, for instance, or supporting module such as aetools and aepack) and maybe they should be, some are (ControlAccessors) which arguably should not. Opinions are welcome. - I'm tempted to put Qt and QuickTime into their own package, especially since I'm also working on porting it to Windows. It would also be in line with Apple's organization. Opinions? - Should we get rid of the Res/Resource dichotomy, where the first is the extension module and the second is the Python module with the constants? We could simply import the extension module functionality into the Python module, at the expense of a rather large namespace. - Should we have a Carbon.Carbon module that simply imports the whole world, so that "from Carbon.Carbon import *" is pretty much equivalent to the C #include <Carbon/Carbon.h>? - Should we put all the other Mac modules into a Mac package? This will make MacPython programs a lot more verbose, but that is a good thing too if people try to port Mac Python scripts to other platforms. Should the Carbon package then be a sub-package of the Mac package? Another change related to the OSX growth path is that there is a new module macresource that you can use to easily open a resource file accompanying your script. Use "macresource.need("DLOG", MY_DIALOG_ID, "name.rsrc") and if the given resource is not available (it _is_ available if your script has been turned into an applet) the given resource file will be opened. This method will eventually also contain the magic needed to open the resource file on OSX MachO Python. ... and more ------------ A feature that I am not sure about (so: feedback!) is that if you open a textfile for reading MacPython will now accept either unix linefeeds (LF, '\n') or Macintosh linefeeds (CR, '\r') and present both of them as '\n'. This is done on a low level, so it works for files opened by scripts as well as for your scripts and modules itself. This can be turned off with a preference/startup option. But: - this works only for input, and there's no way to find out what the original linefeed convention of the file was. - Windows \r\n linefeeds are not supported and get turned into \n\n. What to install --------------- The optional parts in this distribution are - TK+PIL: Tkinter and support modules, plus Imaging, the Python image manipulation package (allows you to read, write and display images and do lots of operations on them). For Carbon MacPython you only get PIL: there is no Tcl/Tk for Carbon yet. This is the reason Classic MacPython is also installed on MacOSX: it allows you to run Tkinter applications, albeit in the Classic box. - img: another imaging package. Has more file format support and is faster than imaging, but has only limited operations on images. There is a bridge between the packages. - Numeric: the LLNL Numeric Python extension. All sorts of nifty operations on matrices and such. This is the most recent version from the sourceforge archive. Numeric has moved from Extensions to :Lib:site-python, by the way, see the release notes. - Developers kit: all header files and some tools and sample projects to get you started on writing Python extensions if you have CodeWarrior. All these except the DevKit are installed with Easy Install. After the installer finishes it automatically launches the appropriate ConfigurePython applet, to finish configuration of your Python. If you run MacOS9 or later (or 8 with CarbonLib installed) you can switch back and forth between the classic and Carbon versions of Python by running either ConfigurePythonClassic or ConfigurePythonCarbon. Moving your Python installation after installing is generally not a good idea. If you have to do this anyway you should remove your preference file, run ConfigurePython and remove all .pyc files. (there's a script zappyc.py that does the latter). If you don't have enough memory: the sizes choosen are somewhat arbitrary, and they are as high as they are so that test.autotest runs with fewer problems. An average Python program can make do with much less memory. Try lowering the application sizes in the finder "get info" window, and seeing whether the resulting python is still usable. After installing ---------------- It is probably a good idea to run the automatic tests. Start Python and "import test.regrtest ; test.regrtest.main()". test_time will fail because MacPython accepts bogus values for mktime(), this will be fixed later. test_descrtut will fail because of a problem with the test itself. Three tests will fail on MacOS9 with MemoryErrors: test_longexp, test_sha and test_zlib (on MacOSX nothing should fail). If you increase the PythonInterpreter memory partition size they will pass (but for longexp you have to increase it by an incredible amount, 400MB is rumoured). It will, however, print some messages about optional features not supported. You should not worry about these, they are modules that are supported by Python on other platforms. Also, if you didn't run compileall before autotesting you may run out of memory the first time you run the tests. test_socket may also fail if you have no internet connection. Please also read the Relnotes file for other minor problems with this distribution. Using Python is most easily done from the IDE, which has a builtin editor, debugger and other goodies. The alternative is to use PythonInterpreter, which is the lowlevel interpreter with a console-window only (similar to Unix Python). If your program uses Tkinter you MUST run it under PythonInterpreter, Tkinter and IDE are incompatible and your program will fail in strange ways. Uninstalling ------------ Two items are installed in the system folder: the interpreter shared libraries PythonCore and PythonCoreCarbon lives in the Extensions folder and the "Python 2.2a3 Preferences" file in the Python subfolder in the Preferences folder. All the rest of Python lives in the folder you installed in. On OSX the libraries are installed in /Library/CFMSupport. There is a nasty bug in OSX that is triggered by Python: if any orphaned aliases are left in /Library/CFMSupport your machine will start to behave very badly. 2.1 beta installers triggered this problem if you simply threw away your Python folder, so if you installed a 2.1beta you should clean out the aliases in /Library/CFMSupport too. The final 2.1 and 2.1.1 installers always copied the shared libraries on OSX, so it does not have the problem anymore. Things to see ------------- Start off at Mac:Demo:index.html. Read at least the first few sections. There are also some interesting files in the "Relnotes" folder that may contain useful information. There is also a first stab at documentation (plus examples) in the Mac:Demo folder. The toplevel Demo folder has machine-independent demos. The Mac:Lib:test folder also has some programs that show simple capabilities of various modules. The ":Mac:scripts" folder has some sample scripts. Some are useful, some are just interesting to look at to see how various things work. The MkDistr, mkapplet and fullbuild scripts (plus the ones mentioned above) may help you to understand how to use AppleEvents and various other toolboxes from python. Other mac-specific goodies can be found in :Mac:Tools, of which the IDE sources and a CGI framework deserve special mention. The 'img' group of modules, which handles I/O of many different image formats is included, but without documentation. You can find docs at ftp://ftp.cwi.nl/pub/jack/python/img (or somewhere around there). Finally there is a Mac:Contrib folder which contains some contributed software. Upgrading from older Python releases ------------------------------------ Python releases are independent of each other, with separate Preferences files, shared library names, etc. The good news is that this means you can keep your older version around if you are unsure whether to upgrade. The bad news is that your old preference settings are lost and you have to set them again. After you are satisfied that 2.2a3 works as expected you can trash anything in the system folder that has "python" in the name and not "2.2a3". The ConfigurePython... applets will try to detect incompatible preferences files and offer to remove them. This means that re-running ConfigurePython after a second install of the same MacPython version (or after moving the Python folder) should fix things up correctly. The installer ------------- The installer for this product was created using Installer VISE from MindVision Software. For more information on Installer VISE, contact: MindVision Software 7201 North 7th Street Lincoln, NE 68521-8913 Voice: 402-477-3269 Fax: 402-477-1395 Internet: mindvision@mindvision.com http://www.mindvision.com Just van Rossum <just@letterror.nl> created the initial version of the installer (with Installer Vise Lite), and Jack worked from there. Thanks! ------- Thanks go to the whole Python community with Guido in the lead, of course. Mac-specific thanks go to the pythonmac-sig, Just van Rossum, Corran Webster, Tony Ingraldi, Erik van Blokland, Bill Bedford, Chris Stern, Gordon Worley, Oliver Steele, M. Papillon, Steven Majewski, David Goodger, Chris Barker, Luc Lefebvre, Tattoo Mabonzo K., Russell Finn, Tom Bridgman, Russel Owen, Pascal Oberndoerfer, Dean Draayer, Alexandre Parenteau, and all the other people who provided feedback, code or both! MacPython includes waste, a TextEdit replacement which is (c) 1998 Marco Piovanelli. A special mention is deserved by Matthias Neeracher, who has written the brilliant unix-compatible GUSI I/O library, without which MacPython would not have sockets or select, and to Alexandre Parenteau, who has ported this library to Carbon. Feedback -------- Send bug reports, suggestions, contributions and fanmail to <jack@cwi.nl>. However, a better way to discuss MacPython is to join the <pythonmac-sig@python.org> mailing list, which is explicitly meant for this purpose. Jack Jansen Oratrix Development BV Valeriusplein 30 Amsterdam the Netherlands <jack@cwi.nl>, http://www.cwi.nl/~jack