- 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 :)
Removed "#undef HAVE_HYPOT" line from Borland config, as suggested.
Whether this will break some other Borland usage is a good question I
can't answer.
Curious: the MS docs say stati64 etc are supported even on Win95, but
Win95 doesn't support a filesystem that allows partitions > 2 Gb.
test_largefile: This was opening its test file in text mode. I have no
idea how that worked under Win64, but it sure needs binary mode on Win98.
BTW, on Win98 test_largefile runs quickly (under a second).
pyport.h: typedef a new Py_intptr_t type.
DELICATE ASSUMPTION: That HAVE_UINTPTR_T implies intptr_t is
available as well as uintptr_t. If that turns out not to be
true, things must get uglier (C99 wants both, so I think it's
an assumption we're *likely* to get away with).
thread_nt.h, PyThread_start_new_thread: MS _beginthread is documented
as returning unsigned long; no idea why uintptr_t was being used.
Others: Always use Py_[u]intptr_t, never [u]intptr_t directly.
SF patch #103683: Alternative dll version resources.
Changes similar to the patch. MarkH should review.
File version and Product version text strings now 2.1a2.
64-bit file and product version numbers are now
PY_MAJOR_VERSION, PY_MINOR_VERSION, messy, PYTHON_API_VERSION
where
messy = PY_MICRO_VERSION*1000 + PY_RELEASE_LEVEL*10 + PY_RELEASE_SERIAL
Updated company name to "Digital Creations 2".
Copyright now lists Guido; "C in a circle" symbol used instead of (C).
Comments added so this is less likely to get flubbed again, and
#if/#error guys added to trigger if the version number manipulations
above overflow.
Wasn't built on Windows; not in config.c either.
Module init function missing DL_EXPORT magic.
test_xreadline output file obviously wrong (started w/ "test_xrl").
test program very unclear about what was expected.
(I had explicitly disabled it a while ago, possibly unecessarily, along with
rgbimg, audioop, and imageop, which are advertised as "not for 64-bit
platforms.)
ceval.c:
define recurion_limit (static), default value is 2500
define Py_GetRecursionLimit and Py_SetRecursionLimit
raise RuntimeError if limit is exceeded
PC/config.h:
remove plat-specific definition
sysmodule.c:
add sys.(get|set)recursionlimit
This patch makes it possible to use gnu-win32 and lcc-win32
(http://www.cs.virginia.edu/~lcc-win32/) compilers to build
extension modules. It adds compiler specific sections to
PC/config.h .
It also extends the Borland compiler section. This has then two parts,
one for Win32 and the other one for the rest. The Win32 part
should be almost complete.
*** This patch is not intended to make it possible to compile
Python with these compilers, it is intended to be able to
use these compilers to build extension modules. ****
comments, docstrings or error messages. I fixed two minor things in
test_winreg.py ("didn't" -> "Didn't" and "Didnt" -> "Didn't").
There is a minor style issue involved: Guido seems to have preferred English
grammar (behaviour, honour) in a couple places. This patch changes that to
American, which is the more prominent style in the source. I prefer English
myself, so if English is preferred, I'd be happy to supply a patch myself ;)
Barry Scott). it appears to solve the problem on NT
and 2000, but not on Windows 95.
in other words, it's better than before, but not per-
fect. I'll leave the patch open for now.
pointed out some of the problems he had following the instructions,
and I stumbled into the others: MSVC has changed in several
respects, Python has changed the directories into which it builds
its own Windows outputs, and we grew the unusual scheme of
appending "_d" to the names of debug-mode output files.
This should all work with VC6 + CVS Python now. Some other Windows
geek please confirm! And the less you know, the better <0.5 wink>.
Explanations and examples for versions of MSVC before 6, and
versions of Python before 2.0b1, have been removed, because
they're too different and so confuse life. This last step I OK'ed
with Guido first (indeed, 'twas his idea!).
Trent Mick <trentm@activestate.com>:
Fix PC/msvcrtmodule.c and PC/winreg.c for Win64. Basically:
- sizeof(HKEY) > sizeof(long) on Win64, so use PyLong_FromVoidPtr()
instead of PyInt_FromLong() to return HKEY values on Win64
- Check for string overflow of an arbitrary registry value (I know
that ensuring that a registry value does not overflow 2**31 characters
seems ridiculous but it is *possible*).
Closes SourceForge patch #100517.
64-bit readiness (the config values are needed for patches that I will
be submitting later today. The changes are as follows:
- add SIZEOF_OFF_T #define's to PC/config.h (it was already in configure.in)
- add SIZEOF_TIME_T #define to PC/config.h and configure
Needed for some buffer overflow checking because sizeof(time_t) is
different on Win64.
- add SIZEOF_FPOS_T #define
Needed for the Win64 large file support implementation.
- add SIZEOF_HKEY in PC/config.h only
Needed for proper Win32 vs. Win64 handling in PC/winreg.c
- #define HAVE_LARGEFILE_SUPPORT for Win64
- typedef long intptr_t; for all Windows except Win64 (which defines it
itself)
This is a new ANSI (I think) type that is useful (and used by me) for
proper handling in msvcrtmodule.c and posixmodule.c
- indent the nested #ifdef's and #defines in PC/config.h
This is *so* much more readable. There cannot be a compiler
compatibilty issue here can there? Perl uses indented #defines and it
compiles with everything.
errors in some of the hash algorithms. For exmaple, in float_hash and
complex_hash a certain part of the value is not included in the hash
calculation. See Tim's, Guido's, and my discussion of this on
python-dev in May under the title "fix float_hash and complex_hash for
64-bit *nix"
(2) The hash algorithms that use pointers (e.g. func_hash, code_hash)
are universally not correct on Win64 (they assume that sizeof(long) ==
sizeof(void*))
As well, this patch significantly cleans up the hash code. It adds the
two function _Py_HashDouble and _PyHash_VoidPtr that the various
hashing routine are changed to use.
These help maintain the hash function invariant: (a==b) =>
(hash(a)==hash(b))) I have added Lib/test/test_hash.py and
Lib/test/output/test_hash to test this for some cases.
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.
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.
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!
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.
- MS_DLL_ID is now set to "1.5" instead of "1.5.x" so Mark Hammond's
extensions won't have to be changed.
- FILEVERSION and PRODUCTVERSION are set to 1,5,2,1.
(The last number could be the build# or the alpha release# or so.)
From: Dan Pierson <dan@remote.control.com>
To: "Mark Hammond (E-mail)" <MHammond@skippinet.com.au>,
"Guido van Rossum (E-mail)" <guido@cnri.reston.va.us>
Date: Mon, 8 Jun 1998 17:25:07 -0400
RegistryQueryValue requires that its fourth argument be initialized to
the length of the buffer being passed in, this wasn't being done. I
also split the call and status test into two lines with a local variable
so that I could look at the status in the debugger.
Also, here is a new version of import_nt.c, which allows you to register a
Debug module in the registry. While I was there I removed some of the
ugliness - what was I thinking :-)
subdirectories.
All final products go into the current directory (i.e., PCbuild).
Object files go into temp-release and temp-debug.
Debug versions of DLLs have _d appended to their basename, e.g. the
debug version of python15.dll is python15_d.dll, the debug version of
python.exe is python_d.exe, and the debug version of parser.pyd is
parser_d.pyd. (See corresponding patch to importdl.c.) Uniformly
changed all extension modules to use .pyd, not .dll.
is like PyImport_ImporModule(name) but receives the globals and locals
dict and the fromlist arguments as well. (The name is a char*; the
others are PyObject*s).
- use the DLL versions of the C runtime (!)
- change path settings so intermediate files go to Debug/temp or Release/temp
- add resource file to python15.dll (can't remember what this does)
- add a separate project to build the parser module
is now obsolete), and changed the default path calculations.
$PYTHONPATH is now added as a prefix (like it's always been on Unix);
$PYTHONHOME takes precedence over the program pathname; and only one
landmark is needed.
of Python file objects. Added open_osfhandle() (Mark had done some
work for that), get_osfhandle(), setmode(), and the console I/O
functions kbhit(), getch(), getche(), ungetch(), and putch().
lives to the end of the path.
(Still to do: add $PYTHONPATH to the front instead of using it as is;
add the Win32 registry paths as in getpath_nt.c (which can then
retire).)
Date: Fri, 4 Oct 1996 09:08:19 +1000
A couple of things. As I mentioned a while back, I have made the
changes to the registry support, in getpath_nt.c. To recap, there can be:
...\pythonpath = default core Pythonpath
...\pythonpath\Pythonwin = c:\somewhere
etc.
The code simply appends them all. The order can not be guaranteed
(registry limitation) but the "default" is always at the end.
The main reasons for change were the length of the path, but mainly
so an uninstaller can do the right thing.
Andrew MacIntyre
Mark Hammond
Tim Peters
Martin v. Löwis
Guido van Rossum
Neal Norwitz
Barry Warsaw
Neil Schemenauer
Fred Drake
Fredrik Lundh
Trent Mick
Jeremy Hylton
Greg Ward
Thomas Wouters
Roger E. Masse