Started on release notes and readme for 2.2a2.

2 files changed, 113 insertions, 52 deletions

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-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.
 
-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 @@ 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
 ---------------
 
@@ -44,7 +118,7 @@ The optional parts in this distribution are
   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 @@ 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.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 @@ 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 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 @@ 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.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 @@ Known problems
 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.