mirror of https://github.com/python/cpython.git
Started on release notes and readme for 2.2a2.
This commit is contained in:
Jack Jansen
parent
79248aa1e4
commit
028f2d5d89
100
Mac/ReadMe
100
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.
|
||||
|
|
|
|||
65
Mac/Relnotes
65
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.
|
||||
|
|
|
|||
Loading…
Reference in New Issue