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.
diff --git a/Mac/Relnotes b/Mac/Relnotes
index f776efd..6787b86 100644
--- a/Mac/Relnotes
+++ b/Mac/Relnotes
@@ -1,49 +1,36 @@
-Changes in 2.1.1 since 2.1
---------------------------
+Changes in 2.2a2 since 2.1.1
+----------------------------
These release notes refer to Mac-specific changes only. See NEWS (in the Misc folder)
-for machine-independent changes.
+for machine-independent changes. But note that more things may have changed: MacPython
+2.2a2 is built from newer sources than unix/windows 2.2a2 (for CVS users: the r22a2-mac
+tag is what you are looking for).
-- Handling non-ascii characters in sys.path on non-MacRoman systems should be fixed,
- iff MacPython has a codec for the charset. Otherwise you should get an error, at least.
- Pathnames in sys.path also retain their original case again.
-- IDE could crash on corrupt preferences. Fixed.
-- IDE will now work if you use either pre or sre as re.
-- Evt.WaitNextEvent could give an error when bit 15 was set, which could cause a problem
- with IDE in classic mode. Fixed.
-- MacOS8.X users in classic mode had problems with Fm not loading, which also caused
- IDE not working. Fixed.
-- Fm.IsAntiAliasedTextEnabled and Fm.SetAntiAliasedTextEnabled have gone for now, to
- fix the problem above.
-- Disabled the Tkinter file I/O event handler, which was there but didn't work anyway.
-- Problems with loading dynamic modules that are part of a package into BuildApplication-
- generated programs were fixed.
-- The order of the EasyDialogs yes/no/cancel buttons has been conformed to the Mac
- standard.
-- Handling of Dialogs and Windows that were not created by Python is a bit more graceful
- now, which may fix some crashes.
-- Ctl.SendControlMessage has gone. But it didn't work anyway.
-- Various problems with the TextEdit and Waste demos have been fixed.
-- Embedding/extending only: in preparation to allowing the use of MacPython modules in
- unix-Python on OSX the xxx_New and xxx_Convert routines are now optionally vectored via
- glue routines in macglue.c. The only change that may be needed for embedders/extenders is
- that you may want to include pymactoolbox.h in your sources.
-- Embedding/extending only: Most MacPython source is now much more Mach-O friendly, and
- should work with Universal Headers 3.4.
-- Experimental: an Mlte module has been added, an interface to the Multi Lingual Text
- Engine. There is a minimal example in :Mac:Demos:mlte.
-- Experimental: some support for FSRef objects has been added. You can do little more that
- convert them to/from FSSpecs. Carbon only.
-- Experimental: the CF module has some support for CoreFoundation types. CFString
- and CFURL work, to a degree, and can be converted to/from Python strings and Unicode
- objects. Carbon only.
+- The main change is that all toolbox modules have moved to a package called Carbon.
+ So things like "import Res" should be changed to "from Carbon import Res", and
+ "from Res import *" to "from Carbon.Res import *". Please see the readme file for
+ some open questions and join the discussions on pythonmac-sig if you have anything
+ to contribute. Aside from reducing clutter this change will also benefit the
+ port to Mach-O/OSX Python later.
+- On input MacPython now accepts either \n (unix style) or \r (mac style) newlines
+ for text files. This is an experimental feature; again: feedback is requested.
+- There is a new module macresource which makes it easier to open a resource file
+ accompanying your script when the script is not (yet) converted to an applet.
+ This module will later also do the right thing in Mach-O/OSX Python.
+- Threads had a stack that was too small for many serious Python applications (20K).
+ They now get 64K. There is still no overflow check, though.
+- Garbage collection and the gc module have (finally) been enabled.
+- EasyDialogs.ProgressBar now has indeterminate progressbars if you specify maxval=0.
+ This is also the new default. Patch supplied by Dean Draayer.
+- Various outdated scripts have been moved to :Mac:Unsupported.
+- Various outdated items from :Mac:Lib:test have been removed.
What is not in this distribution
--------------------------------
-- The garbage collection mods have not been enabled, mainly due to lack of test-time.
-- Stackless Python/microthreads hasn't been ported to 2.1 yet. If/when it becomes available
+- Stackless Python/microthreads hasn't been ported to 2.2 yet. If/when it becomes available
Just will undoubtedly announce it on pythonmac-sig and the MacPython homepage.
+- The toolbox modules have not been updated to Universal Header 3.4 or CarbonLib 1.4 yet.
Known problems
--------------
@@ -51,7 +38,7 @@
This list is probably incomplete, more problems may be listed on the MacPython homepage,
http://www.cwi.nl/~jack/macpython.html.
-- MacPython 2.1.1 (and MacPython 2.1) will not run correctly on a multiprocessor MacOS X
+- MacPython 2.2a2 (and MacPython 2.1) will not run correctly on a multiprocessor MacOS X
machine, it will quickly deadlock during I/O operations. The GUSI I/O library is suspected,
hints/clues/workarounds are solicited.
- Tkinter does not work under Carbon.