Mercurial > cpython-lru_cache-weakref
annotate Mac/Relnotes-1.1 @ 4566:6403c94de50d legacy-trunk
Added safeguard against failure in __del__.
| author | Guido van Rossum <guido@python.org> |
|---|---|
| date | Wed, 27 Nov 1996 19:39:58 +0000 |
| parents | ea5b13d11a13 |
| children |
| rev | line source |
|---|---|
| 1615 | 1 PYTHON RELEASE NOTES FOR THE MACINTOSH |
| 2 | |
|
1811
ea5b13d11a13
Added macmain.c (separate Mac specific main prog); bump version to 1.1
Guido van Rossum <guido@python.org>
parents:
1648
diff
changeset
|
3 VERSION 1.1 |
| 1615 | 4 |
| 5 For the most part, Python on the Mac works just like Python under UNIX. | |
| 6 The most important differences are: | |
| 7 | |
| 8 - Since there is no shell environment on the Mac, the start-up file | |
| 9 has a fixed name: PythonStartup. If a file by this name exists | |
| 10 (either in the current folder or in the system folder) it is executed | |
| 11 when an interactive interpreter is started. | |
| 12 | |
| 13 - The default search path for modules is different: first the current | |
|
1648
7ac4e49791f4
Removed some random ^D characters
Guido van Rossum <guido@python.org>
parents:
1615
diff
changeset
|
14 directory is searched, then the subdirectories 'lib', 'lib:stdwin' and |
| 1615 | 15 'demo'. As always, you can change this (e.g. in your PythonStartup |
| 16 file) by assigning or appending to sys.path -- use Macintosh pathnames! | |
| 17 (The default contains no absolute paths because these are unlikely | |
| 18 to make sense on other people's hard disks.) | |
| 19 | |
| 20 - The user interface for typing interactive commands is different. | |
| 21 This is actually the THINK C console I/O module, which is based on | |
| 22 the Mac toolbox TextEdit. A standard Edit menu provides Cut, Copy, | |
| 23 Paste and Clear (Undo is only there for Desk Accessories). A minimal | |
| 24 File menu provides Quit, which immediately exits the application, | |
| 25 without the usual cleanup. You can Copy from previous output, | |
| 26 but you can't scroll back beyond the 24x80 screen. The TAB key | |
| 27 always brings you to the end of the current input line; indentation | |
| 28 must be entered with spaces (a single space is enough). | |
| 29 End-of-file is generated by Command-D; Command-Period interrupts. | |
| 30 There is an annoying limit in the length of an input line to a single | |
| 31 screen line (less the prompt). Use \ to input long statements. | |
| 32 Change your program if it requires long lines typed on input. | |
| 33 Even though there is no resize box, the window can be resized by | |
| 34 dragging its bottom right corner, but the maximum size is 24x80. | |
| 35 | |
| 36 - Tabs in module files are interpreted as 4 (four!) spaces. This is | |
| 37 consistent with most Mac editors that I know. For individual files | |
| 38 you can change the tab size with a comment like | |
| 39 | |
| 40 # vi:set tabsize=8: | |
| 41 | |
| 42 (exactly as shown here, including the colons!). If you are consistent | |
| 43 in always using tabs for indentation on UNIX, your files will be | |
| 44 parsed correctly on the Mac, although they may look funny if you | |
| 45 have nicely lined-up comments or tables using tabs. Never using tabs | |
| 46 also works. Mixing tabs and spaces to simulate 4-character indentation | |
| 47 levels is likely to fail. | |
| 48 | |
| 49 - You can start a script from the Finder by selecting the script and | |
| 50 the Python interpreter together and then double clicking. If you | |
| 51 make the owner of the script PYTH (the type should always be TEXT) | |
| 52 Python will be launched if you double click it! | |
| 53 There is no way to pass command line arguments to Python scripts. | |
| 54 | |
| 55 - The set of built-in modules is different: | |
| 56 | |
| 57 = Operating system functions for the 'os' module is provided by the | |
| 58 built-in module 'mac', not 'posix'. This doesn't have all the | |
| 59 functions from posix, for obvious reasons (if you know the Mac | |
| 60 O/S a little bit). The functions in os.path are provided by | |
| 61 macpath, they know about Mac pathnames etc. | |
| 62 | |
| 63 = None of the UNIX specific modules ('socket', 'pwd', 'grp' etc.) | |
| 64 exists. | |
| 65 | |
| 66 = Module 'stdwin' is always available. It uses the Mac version of | |
| 67 STDWIN, which interfaces directly with the Mac toolbox. The most | |
| 68 important difference is in the font names; setfont() has a second | |
| 69 argument specifying the point size and an optional third one | |
| 70 specifying the variation: a single letter character string, | |
| 71 'i' for italics, 'b' for bold. Note that when STDWIN is waiting | |
| 72 for events, the standard File and Edit menus are inactive but | |
| 73 still visible, and (most annoyingly) the Apple menu is also inactive; | |
| 74 conversely, menus put up by STDWIN are not active when the Python is | |
| 75 reading from the keyboard. If you open Python together with a text | |
| 76 file containing a Python script, the script will be executed and | |
| 77 a console window is only generated when the script uses standard | |
| 78 input or output. A script that uses STDWIN exclusively for its I/O | |
| 79 will have a working Apple menu and no extraneous File/Edit menus. | |
| 80 (This is because both stdwin and stdio try to initialize the | |
| 81 windowing environment; whoever gets there first owns the Apple menu.) | |
| 82 LIMITATIONS: a few recent additions to STDWIN for X11 have not yet | |
| 83 been added to the Mac version. There are no bitmap objects, and | |
| 84 the setwinpos() and setwinsize() methods are non--functional. | |
| 85 | |
| 86 - Because launching an application on the Mac is so tedious, you will | |
| 87 want to edit your program with a desk accessory editor (e.g., Sigma | |
| 88 edit) and test the changed version without leaving Python. This is | |
| 89 possible but requires some care. Make sure the program is a module | |
| 90 file (filename must be a Python identifier followed by '.py'). You | |
| 91 can then import it when you test it for the first time. There are | |
| 92 now three possibilities: it contains a syntax error; it gets a runtime | |
| 93 error (unhandled exception); or it runs OK but gives wrong results. | |
| 94 (If it gives correct results, you are done testing and don't need | |
| 95 to read the rest of this paragraph. :-) Note that the following | |
| 96 is not Mac-specific -- it's just that on UNIX it's easier to restart | |
| 97 the entire script so it's rarely useful. | |
| 98 | |
| 99 Recovery from a syntax error is easy: edit the file and import it | |
| 100 again. | |
| 101 | |
| 102 Recovery from wrong output is almost as easy: edit the file and, | |
| 103 instead of importing it, call the function reload() with the module | |
| 104 name as argument (e.g., if your module is called foo, type | |
| 105 "reload(foo)"). | |
| 106 | |
| 107 Recovery from an exception is trickier. Once the syntax is correct, | |
| 108 a 'module' entry is placed in an internal table, and following import | |
| 109 statements will not re-read the file, even if the module's initialization | |
| 110 terminated with an error (one reason why this is done is so that | |
| 111 mutually recursive modules are initialized only once). You must | |
| 112 therefore force re-reading the module with reload(), however, if this | |
| 113 happens the first time you try to import the module, the import statement | |
| 114 itself has not completed, and your workspace does not know the module | |
| 115 name (even though the internal table of moduesl does!). The trick is | |
| 116 to first import the module again, then reload it. For instance, | |
| 117 "import foo; reload(foo)". Because the module object already exists | |
| 118 internally, the import statement does not attempt to execute the | |
| 119 module again -- it just places it in your workspace. | |
| 120 | |
| 121 When you edit a module you don't have to worry about the corresponding | |
| 122 '.pyc' file (a "compiled" version of the module, which loads much faster | |
| 123 than the textual version): the interpreter notices that the '.py' file | |
| 124 has changed (because its modification time has changed) and ignores the | |
| 125 '.pyc' file. When parsing is successful, a new '.pyc' file is written; | |
| 126 if this fails (no write permission, disk full or whatever) it is | |
| 127 silently skipped but attempted again the next time the same module | |
| 128 is loaded. (Thus, if you plan to place a Python library on a read-only | |
| 129 disk, it is advisable to "warm the cache" by making the disk writable | |
| 130 and importing all modules once. The standard module 'importall' helps | |
| 131 in doing this.) |