Facilitate cross-compilation by having binaries in separate Win32 and x64 directories.
Rationalized configs by making proper use of platforms/configurations.
Remove pythoncore_pgo project.
Add new PGIRelease and PGORelease configurations to perform Profile Guided Optimisation.
Removed I64 support, but this can be easily added by copying the x64 platform settings.
Renames functional extension module to _functools and adds a Python
functools module so that utility functions like update_wrapper can be
added easily.
Export the COM entry point functions.
Note that there are several conflicting base addresses defined for
other extensions, also not all are listed in dllbase_nt.txt.
objimpl.h, pymem.h: Stop mapping PyMem_{Del, DEL} and PyMem_{Free, FREE}
to PyObject_{Free, FREE} in a release build. They're aliases for the
system free() now.
_subprocess.c/sp_handle_dealloc(): Since the memory was originally
obtained via PyObject_NEW, it must be released via PyObject_FREE (or
_DEL).
pythonrun.c, tokenizer.c, parsermodule.c: I lost count of the number of
PyObject vs PyMem mismatches in these -- it's like the specific
function called at each site was picked at random, sometimes even with
memory obtained via PyMem getting released via PyObject. Changed most
to use PyObject uniformly, since the blobs allocated are predictably
small in most cases, and obmalloc is generally faster than system
mallocs then.
If extension modules in real life prove as sloppy as Python's front
end, we'll have to revert the objimpl.h + pymem.h part of this patch.
Note that no problems will show up in a debug build (all calls still go
thru obmalloc then). Problems will show up only in a release build, most
likely segfaults.
for Python 2.4 caused a segfault when post_install_script was used.
The reason was that the file handle passed to PyRun_SimpleFile() was
created with MSVCRT.DLL, but Python 2.4 uses MSVCR71.DLL.
So, I replaced PyRun_SimpleFile() with PyRun_SimpleString(). The
segfault is gone, but the output of the postinstall script doesn't
show up, because still freopen() from MSVCRT is used.
Already backported.
Python was installed with the 'only for me' option. The registry key
had a hardcoded '2.3' in it where the python version chosen for
installation should be used instead.
Will backport myself.
today. pyconfig.h can override it if not, and can also override
Py_IS_INFINITY now. Py_IS_NAN and Py_IS_INFINITY are overridden now
for Microsoft compilers, using efficient MS-specific spellings.
This was probably fixed in rev 1.32 of getpath.c, but there are so
many paths thru the code that invoke joinpath() it's not at all
obvious that it *is* fixed. It doesn't help confidence that a crucial
precondition for calling joinpath() was neither documented nor verified.
It is now, and joinpath() will barf with a fatal error now rather than
overrun the buffer, if the precondition isn't met.
Note that this patch only changes the Windows flavor. I attached another
patch to the bug report for the POSIX flavor (which I can't test
conveniently).
to address bugs:
[ 555812 ] installing extension w/o admin rights
[ 555810 ] removing extensions without admin rights
* When enumerating the Python versions found, also remember the HKEY
they were found under.
* When installing, if Python was installed under HKCU, we will too.
If Python was installed under HKLM, we check the permissions of
the current user, and install where we can.
* The "root" key we use is a global variable - all registry setting and
delete functions use this global rather than a hardcoded HKLM.
* A new entry is written to the install log, indicating the key we used.
Uninstallation is based on this key.
* 'tempnam()' is used rather than 'tmpnam()' - 'tmpnam' creates a temp
file on the root of the current drive, and if this is readonly would
explain the 'freopen' errors occasionally reported. 'tempnam'
creates the temp file in the %TEMP% directory.
it from the install directory (as reported by the registry) in case it
is not found on the default Loadlibrary search path.
Fixes SF 935091: bdist_winist post-install script fails on non-admin Python
Already backported.
by bdist_wininst *must* use the same runtime libary as the Python
version.
Actually this means the Python version where the installer is run, not
the one which is used to build it. Must think about that - for now I
assume MSVC6 is used up to Python 2.3, and MSVC7.1 is used starting at
Python 2.4.
So the filename for wininst.exe is now wininst-6.exe for the Release
version and wininst-6_d.exe for the Debug version, when built with
MSVC6.
install.c: support for a 'pre-install-script', run before anything has
been installed. Provides a 'message_box' module function for use by
either the pre-install or post-install scripts.
bdist_wininst.py: support for pre-install script. Typo (build->built),
fixes so that --target-version can still work, even when the
distribution has extension modules - in this case, we insist on
--skip-build, as we still can't actually build other versions.
again. Removed the following subprojects and folded them into pythoncore,
to match what's being done under VC7. We *can* build the core DLL
under VC6 again after this:
datetime.dsp
winreg.dsp
parser.dsp
_sre.dsp
_csv.dsp
mmap.dsp
_symtable.dsp
isn't checked, and it *is* possible that a very large alloca() call is
made, e.g. when a large registry value is being read. I don't know if
alloca() in that case returns NULL or returns a pointer pointing outside
the stack, and I don't want to know -- I've simply replaced all calls to
alloca() with either PyMem_Malloc() or PyString_FromStringAndSize(NULL,)
as appropriate, followed by a size check. This addresses SF buf 851056.
Will backport to 2.3 next.
change the version number is no longer required.
Instead, a make_versioninfo.exe is compiled, which spits out an
include file for python_nt.rc.
Will backport to 2.3
- more clean up of the generated import library definiton (.DEF file)
following checking of patch 770521, and tightening of the sed regexps.
- use -O3 even with gcc 2.8.1 - worth nearly 10% with 2.3; worth
nothing with 2.2.x.
- clean up a couple of whitespace issues introduced by a cut'n'paste.
- separate the building of the core from the wrapper executables and the
external modules (.PYDs), based on the Py_BUILD_CORE define;
- clean up the generated import library definiton (.DEF file) to remove
references to a number of non-static symbols that aren't part of the
Python API and which shouldn't be exported by the core DLL;
- compile the release build with -fomit-frame-pointer, for a small
performance gain;
- make "make clean" remove byte compiled Python library files.
reorganise modules, so that most standard extensions are built into
the Python DLL. this slightly improves performance; reduces
fragmentation of address spaces and slightly reduces memory footprint.
- restructure build for modules now in Python DLL
README.os2emx
- clean out old cruft no longer appropriate now that EMX port builds
from CVS
- reflect move of modules into core DLL
- add section on building from source
PC/python_nt.rc sets up the DLL version resource (displayed when you
right-click on the DLL and select Properties).
PCbuld/python20.wse sets up the installer version resource (displayed
when you right-click on the installer .exe and select Properties). Turns
out this one hadn't been updated since 2001 <frown>!
- add new modules (zipimport, datetime, _random, bz2, _symtable)
- build pyexpat with expat sources from Python distribution
- regression test with and without compiled bytecode
- new import hooks in import.c, exposed in the sys module
- new module called 'zipimport'
- various changes to allow bootstrapping from zip files
I hope I didn't break the Windows build (or anything else for that
matter), but then again, it's been sitting on sf long enough...
Regarding the latest discussions on python-dev: zipimport sets
pkg.__path__ as specified in PEP 273, and likewise, sys.path item such as
/path/to/Archive.zip/subdir/ are supported again.
Changed the MSVC project file to create the exe in the
lib/distutils/command directory, bdist_wininst.py must still be
changed to use it.
Also changed to use the same zlib as the zlib module - this has the nice
sideeffect that now the buggy 1.1.3 version is no longer used.
Most of the source files now conform to PEP 7, except for the maximum
line length. Windows api programming in 78 character lines =:(.
README.txt is a new file, but still empty except for placeholders.
This changes sys.version under Microsoft builds to include the MS compiler
version number (_MSC_VER). Since VC 6 and VC 7 are apparently
incompatible, and both can be installed on a single box, distutils needs
some way to figure out which version of MSVC a given Python was compiled
under.
As also suggested by MvL, got rid of #ifdef'ery for the defunct _M_ALPHA
target.
Bugfix candidate? Hard to say. As far as I'm concerned, VC 7 wasn't
a supported platform in the 2.2 line. If somebody thinks it should be,
they can do the work.
CAUTION: The Python test still has many failures, but I'm out of time
for this now (already took much longer than hoped to get this far).
The base bz2 library does pass its own tests (see next).
CAUTION: People building on Windows have to download and build tne
bz2 compression libraries now. See PCbuild\readme.txt for complete
instructions.
comments everywhere that bugged me: /* Foo is inlined */ instead of
/* Inline Foo */. Somehow the "is inlined" phrase always confused me
for half a second (thinking, "No it isn't" until I added the missing
"here"). The new phrase is hopefully unambiguous.
- update DLL version number
- add files required for 2.3 (no changes to modules though)
- restructure build of pgen.exe
NOTE: As I don't have the VACPP compiler, these changes are untested.
Apart from slightly re-ordering some file lists, and matching file name
casing, I believe these changes are the minimum necessary to build 2.3
with VACPP.
- the security fixes to tempfile have lead to test_tempfile wanting
to create 100 temporary files. as the EMX default is only 40,
the number of file handles has been bumped (up to 250).
- changes to pgen have required restructuring its build support.
MSDN sample programs use it, apparently in error. The correct name
is WIN32_LEAN_AND_MEAN. After switching to the correct name, in two
cases more was needed because the code actually relied on things that
disappear when WIN32_LEAN_AND_MEAN is defined.
These built-in functions are replaced by their (now callable) type:
slice()
buffer()
and these types can also be called (but have no built-in named
function named after them)
classobj (type name used to be "class")
code
function
instance
instancemethod (type name used to be "instance method")
The module "new" has been replaced with a small backward compatibility
placeholder in Python.
A large portion of the patch simply removes the new module from
various platform-specific build recipes. The following binary Mac
project files still have references to it:
Mac/Build/PythonCore.mcp
Mac/Build/PythonStandSmall.mcp
Mac/Build/PythonStandalone.mcp
[I've tweaked the code layout and the doc strings here and there, and
added a comment to types.py about StringTypes vs. basestring. --Guido]
457466: popenx() argument mangling hangs python
226766: popen('python -c"...."') tends to hang
Fixes argument quoting in w9xpopen.exe for Windows 9x. w9xpopen.exe
also never attempts to display a MessageBox when not executed
interactively.
Added test_popen() test. This test currently just executes
"python -c ..." as a child process, and checks that the expected
arguments were all recieved correctly by the child process. This
test succeeds for me on Win9x, win2k and Linux, and I hope it does
for other popen supported platforms too :)
Georg Brandl
Martin v. Löwis
Kristján Valur Jónsson
Neal Norwitz
Barry Warsaw
Andrew MacIntyre
Nick Coghlan
Tim Peters
Thomas Heller
Fredrik Lundh
Walter Dörwald
Fred Drake
Raymond Hettinger
Trent Mick
Peter Astrand
Hye-Shik Chang
Mark Hammond
Skip Montanaro
Guido van Rossum
Just van Rossum