| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
noted the minimum recommended version in the message.
|
|
|
|
|
| |
commented by Fred Drake, to prevent usage of sufficiently broken GCC
versions.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Python on UNIX now trusts PYTHONHOME unconditionally
Modules/getpath.c:
Landmark changed to os.py.
Setting PYTHONHOME now unconditionally sets sys.prefix
(and sys.exec_prefix). No further checks are done whether the
standard lib can be found in that location or not. This is in
sync with the PC subdir getpath implementations.
PC/getpathp.c:
Landmark changed to os.py.
PC/os2vacpp/getpathp.c:
Landmark changed to os.py.
Note: BAW's checkin on exceptions.c eliminates earlier concerns about
a bogus PYTHONHOME value leading to a core dump. Instead it causes a
useless sys.path and prevents imports.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use "win32" for sys.platform on Win64 instead of "win32" because:
1. While it may be confusing to the Python scriptor on Win64 that he has to
check for win*32*, that is something that he will learn the first time. It
is better than the alternative of the scriptor happily using "win64" and
then that code not running on Win32 for no good reason.
2. The main question is: is Win64 so much more like Win32 than different from
it that the common-case general Python programmer should not ever have to
make the differentiation in his Python code. Or, at least, enough so that
such differentiation by the Python scriptor is rare enough that some other
provided mechanism is sufficient (even preferable). Currently the answer
is yes. Hopefully MS will not change this answer.
|
|
|
|
|
|
| |
The following modules are specifically excluded in the Win64 build:
audioop, binascii, imageop, rgbimg. They are advertised as heavily 32-bit
dependent. [They should probably be fixed! --GvR]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Changes to PC\config.[hc] for Win64. MSVC defines _WINxx to differentiate the
various windows platforms. Python's MS_WINxx are keyed off of these. Note
that _WIN32 (and hence MS_WIN32 in Python) are defined on Win32 *and* on
Win64. This is for compatibility reasons. The idea is that the common case is
that code specific to Win32 will also work on Win64 rather than being
specific to Win32 (i.e. there is more the same than different in WIn32 and
Win64).
The following modules are specifically excluded in the Win64 build:
audioop, binascii, imageop, rgbimg. They are advertised as heavily 32-bit
dependent. [They should probably be fixed! --GvR]
The patch to config.h looks big but it really is not. These are the effective
changes:
- MS_WINxx are keyed off _WINxx
- SIZEOF_VOID_P is set to 8 for Win64
- COMPILER string is changed appropriately for Win64
|
|
|
|
|
|
|
|
|
|
| |
For more comments, read the patches@python.org archives.
For documentation read the comments in mymalloc.h and objimpl.h.
(This is not exactly what Vladimir posted to the patches list; I've
made a few changes, and Vladimir sent me a fix in private email for a
problem that only occurs in debug mode. I'm also holding back on his
change to main.c, which seems unnecessary to me.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* Base address for all extension modules updated. PC\dllbase_nt.txt
also updated. Erroneous "libpath" directory removed for all
projects.
* winsound module moved from a builtin module to an extension
module. This was done primarily to avoid Python16.dll needing to
pull in winmm.dll. Really dumb test added for winsound - but if
nothing else it ensures the module imports.
|
|
|
|
| |
moved to their own DLLs, or are obsolete (soundex).
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
light of three different situations: (1) running from build; (2)
running from installed; (3) running without being able to find an
installation (e.g. as a COM object). The system paths in the
repository are only used for (3); the path deduced from the
installation location are used otherwise. PYTHONHOME overrides in all
cases.
Read the comments for more details.
|
| |
|
|
|
|
|
|
| |
running out of the build directory. This means that it will no longer
try to use an older version of the library when an older version has
been installed.
|
|
|
|
| |
me half an hour to find why it was still linking with python15.dll!)
|
| |
|
|
|
|
| |
(I did this under VC++ 5.0 -- hope this doesn't break anything.)
|
|
|
|
| |
compilation on NT Alpha. Mostly added casts etc.
|
|
|
|
| |
Define Py_DEBUG when compiling in debug mode. (Is that a good idea?)
|
|
|
|
|
|
| |
Attached is a context diff to winsound.c that adds a Beep() function
to play a sound through the PC speaker. Seems to make sense to have
this added, so I just went and did it!
|
|
|
|
| |
0.5 MB of the 1 MB available by default for stack on Win32 platforms).
|
| |
|
|
|
|
| |
(I can't even display this on NT, maybe Win/98 can?)
|
|
|
|
| |
remove the VC++ 4.0 project file; remove the unused _tkinter extern defs.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
audioop module; this was no longer defined. Use MS_WINDOWS instead.
(I have a feeling that this was for the WATCOM port; too bad.)
|
| |
|
|
|
|
| |
last patch to this file: use pathLen, not bufSize, as the initializer.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
native format, as void* (translated to Python int or long).
Also adds PyLong_FromVoidPtr and PyLong_AsVoidPtr to longobject.c.
|
| |
|
| |
|
|
|
|
|
|
| |
The MS compiler doesn't call it 'long long', it uses __int64,
so a new #define, LONG_LONG, has been added and all occurrences
of 'long long' are replaced with it.
|
| |
|
|
|
|
| |
The registry always comes first and the default is always appended.
|
| |
|
|
|
|
|
| |
Make an explicit test for whether the prefix is in fact the
source directory, and then don't use the registry.
|
| |
|
|
|
|
|
| |
when it gets the path from the registry, it no longer appends the
default path to the end (which would mostly be a duplication).
|
|
|
|
| |
The real change is that it now includes "Python.h".
|