Started on release notes and readme for 2.2a2.
diff --git a/Mac/ReadMe b/Mac/ReadMe
index e2e80b8..5ff575b 100644
--- a/Mac/ReadMe
+++ b/Mac/ReadMe
@@ -1,16 +1,20 @@
-How to install Python 2.1.1 on your Macintosh
+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.
+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
@@ -24,11 +28,6 @@
Mac:Demo. The documentation is sparse, but it will have to serve for
now. The documentation is in HTML format, start with index.html.
-Caveats
--------
-Aside from the general new Python 2.1.1 features compared to 2.0 the main
-feature of this release is Carbon support.
-
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
@@ -36,6 +35,81 @@
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
---------------
@@ -44,7 +118,7 @@
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 MacOS9 box.
+ 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.
@@ -104,7 +178,7 @@
Two items are installed in the system folder: the interpreter shared
libraries PythonCore and PythonCoreCarbon lives in the Extensions folder and the
-"Python 2.1.1 Preferences" file in the Python subfolder in 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.
@@ -113,7 +187,7 @@
/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 installer always copied the shared libraries on OSX, so it does
+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
@@ -153,11 +227,11 @@
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.1.1 works as expected you can trash
+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.1.1".
+"2.2a2".
-As of 2.1 the ConfigurePython applets will try to detect incompatible preferences
+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.