'warnings' code in places where it was previously not possible (e.g., the
parser). It could also potentially lead to a speed-up in interpreter start-up
if the C version of the code (_warnings) is imported over the use of the
Python version in key places.
Closes issue #1631171.
It was only used as a helper in types.py to access types (GetSetDescriptorType and MemberDescriptorType),
when they can easily be obtained with python code.
These expressions even work with Jython.
I don't know what the future of the types module is; (cf. discussion in http://bugs.python.org/issue1605 )
at least this change makes it simpler.
in pyconfig.h, NTDDI_WIN2KSP4 is not *yet* defined, but will be at some point on some modules.
Let this line even for older SDKs, they don't use it anyway.
I applied the same changes manually to VS7.1 and VC6 files; completely untested.
(Christian, don't try too hard merging this change into py3k.
It will be easier to do the same work again on the branch)
Added Py_BUILD_CORE_MODULES macro to set WINVER and NTDDI_VERSION to Windows 2000 for core modules, too
Added -d option to build.bat (same as -c Debug) and fixed warning about /build option
Updated Windows related readme.txt files
based on the VS 2008 build directory to PC/VS8.0. The script
PCbuild/vs8to9.py was added to sync changes from PCbuild to PC/VS8.0.
Kristjan, the initial creator of the PCbuild8 directory is fine with the replacement. I've moved the new version of the VS 2005 build directory next to the other legacy build directories. The new sync script is based on the work of wreck and syncs changes in the project, property and solution files.
* Removed a #define from pyconfig.h. The macro was already defined a few lines higher.
* Fixed path to tix in the build_tkinter.py script
* Changed make_buildinfo.c to use versions of unlink and strcat which are considered safe by Windows (as suggested by MvL).
* Removed two defines from pyproject.vsprops that are no longer required. Both are defined in pyconfig.h and make_buildinfo.c doesn't use the unsafe versions any more (as suggested by MvL).
* Added some more information about PGO and the property files to PCbuild9/readme.txt.
Are you fine with the changes, Martin?
- Reenable modules on x64 that had been disabled aeons ago for Itanium.
- Cleared up confusion about compilers for 64 bit windows. There is only Itanium and x64. Added macros MS_WINI64 and MS_WINX64 for those rare cases where it matters, such as the disabling of modules above.
- Set target platform (_WIN32_WINNT and WINVER) to 0x0501 (XP) for x64, and 0x0400 (NT 4.0) otherwise, which are the targeted minimum platforms.
- Fixed thread_nt.h. The emulated InterlockedCompareExchange function didn´t work on x64, probaby due to the lack of a "volatile" specifier. Anyway, win95 is no longer a target platform.
- Itertools module used wrong constant to check for overflow in count()
- PyInt_AsSsize_t couldn't deal with attribute error when accessing the __long__ member.
- PyLong_FromSsize_t() incorrectly specified that the operand were unsigned.
With these changes, the x64 passes the testsuite, for those modules present.
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.