Staging
v0.5.1
v0.5.1
https://github.com/python/cpython
Revision a4dd011259fa6f3079bd0efd95b3a136c0e3c190 authored by Guido van Rossum on 15 April 2001, 22:16:26 UTC, committed by Guido van Rossum on 15 April 2001, 22:16:26 UTC
and reported to python-dev: because we were calling dict_resize() in PyDict_Next(), and because GC's dict_traverse() uses PyDict_Next(), and because PyTuple_New() can cause GC, and because dict_items() calls PyTuple_New(), it was possible for dict_items() to have the dict resized right under its nose. The solution is convoluted, and touches several places: keys(), values(), items(), popitem(), PyDict_Next(), and PyDict_SetItem(). There are two parts to it. First, we no longer call dict_resize() in PyDict_Next(), which seems to solve the immediate problem. But then PyDict_SetItem() must have a different policy about when *it* calls dict_resize(), because we want to guarantee (e.g. for an algorithm that Jeremy uses in the compiler) that you can loop over a dict using PyDict_Next() and make changes to the dict as long as those changes are only value replacements for existing keys using PyDict_SetItem(). This is done by resizing *after* the insertion instead of before, and by remembering the size before we insert the item, and if the size is still the same, we don't bother to even check if we might need to resize. An additional detail is that if the dict starts out empty, we must still resize it before the insertion. That was the first part. :-) The second part is to make keys(), values(), items(), and popitem() safe against side effects on the dict caused by allocations, under the assumption that if the GC can cause arbitrary Python code to run, it can cause other threads to run, and it's not inconceivable that our dict could be resized -- it would be insane to write code that relies on this, but not all code is sane. Now, I have this nagging feeling that the loops in lookdict probably are blissfully assuming that doing a simple key comparison does not change the dict's size. This is not necessarily true (the keys could be class instances after all). But that's a battle for another day.
1 parent 0aa30b0
Tip revision: a4dd011259fa6f3079bd0efd95b3a136c0e3c190 authored by Guido van Rossum on 15 April 2001, 22:16:26 UTC
Tentative fix for a problem that Tim discovered at the last moment,
Tentative fix for a problem that Tim discovered at the last moment,
Tip revision: a4dd011
readme.txt
Welcome to the "PC" subdirectory of the Python distribution
***********************************************************
*** Note: the project files for MS VC++ 6.0 are now in the
*** PCbuild directory. See the file readme.txt there for build
*** instructions. There is some information below that might
*** still be relevant.
This "PC" subdirectory contains complete project files to make
several older PC ports of Python, as well as all the PC-specific
Python source files. It should be located in the root of the
Python distribution, and there should be directories "Modules",
"Objects", "Python", etc. in the parent directory of this "PC"
subdirectory. Be sure to read the documentation in the Python
distribution.
Python requires library files such as string.py to be available in
one or more library directories. The search path of libraries is
set up when Python starts. To see the current Python library search
path, start Python and enter "import sys" and "print sys.path".
All PC ports use this scheme to try to set up a module search path:
1) The script location; the current directory without script.
2) The PYTHONPATH variable, if set.
3) For Win32 platforms (NT/95), paths specified in the Registry.
4) Default directories lib, lib/win, lib/test, lib/tkinter;
these are searched relative to the environment variable
PYTHONHOME, if set, or relative to the executable and its
ancestors, if a landmark file (Lib/string.py) is found ,
or the current directory (not useful).
5) The directory containing the executable.
The best installation strategy is to put the Python executable (and
DLL, for Win32 platforms) in some convenient directory such as
C:/python, and copy all library files and subdirectories (using XCOPY)
to C:/python/lib. Then you don't need to set PYTHONPATH. Otherwise,
set the environment variable PYTHONPATH to your Python search path.
For example,
set PYTHONPATH=.;d:\python\lib;d:\python\lib\win;d:\python\lib\dos-8x3
There are several add-in modules to build Python programs which use
the native Windows operating environment. The ports here just make
"QuickWin" and DOS Python versions which support a character-mode
(console) environment. Look in www.python.org for Tkinter, PythonWin,
WPY and wxPython.
To make a Python port, start the Integrated Development Environment
(IDE) of your compiler, and read in the native "project file"
(or makefile) provided. This will enable you to change any source
files or build settings so you can make custom builds.
config.h An important configuration file specific to PC's.
config.c The list of C modules to include in the Python PC
version. Manually edit this file to add or
remove Python modules.
testpy.py A Python test program. Run this to test your
Python port. It should produce copious output,
ending in a report on how many tests were OK, how many
failed, and how many were skipped. Don't worry about
skipped tests (these test unavailable optional features).
Additional files and subdirectories for 32-bit Windows
======================================================
python_nt.rc Resource compiler input for python15.dll.
dl_nt.c, import_nt.c
Additional sources used for 32-bit Windows features.
getpathp.c Default sys.path calculations (for all PC platforms).
dllbase_nt.txt A (manually maintained) list of base addresses for
various DLLs, to avoid run-time relocation.
example_nt A subdirectory showing how to build an extension as a
DLL.
IBM VisualAge C/C++ for OS/2
============================
See os2vacpp/readme.txt. This platform is supported by Jeff Rush.
Note for Windows 3.x and DOS users
==================================
Neither Windows 3.x nor DOS is supported any more. The last Python
version that supported these was Python 1.5.2; the support files were
present in Python 2.0 but weren't updated, and it is not our intention
to support these platforms for Python 2.x.
Computing file changes ...
