mirror of https://github.com/python/cpython
289 lines
13 KiB
Plaintext
289 lines
13 KiB
Plaintext
How to install Python 2.2a2 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.2a2 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.2a2.
|
|
------
|
|
|
|
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.
|
|
|
|
But:
|
|
- this works only for input, and there's no way to find out what the original
|
|
linefeed convention of the file was.
|
|
- this is unconditional, so there's no way to turn it off, either on a file-by-file
|
|
basis or globally (but opening binary files works as it always has, of course).
|
|
- 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.autotest".
|
|
|
|
Three tests will fail on MacOS9, all 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.2a2 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.2a2 works as expected you can trash
|
|
anything in the system folder that has "python" in the name and not
|
|
"2.2a2".
|
|
|
|
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
|
|
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
|