Issue 2408: remove the _types module
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.
Use the new PyFile_IncUseCount & PyFile_DecUseCount calls appropriatly
within the standard library. These modules use PyFile_AsFile and later
release the GIL while operating on the previously returned FILE*.
Make file objects as thread safe as the underlying libc FILE* implementation.
close() will now raise an IOError if any operations on the file object
are currently in progress in other threads.
Most code was written by Antoine Pitrou (pitrou). Additional testing,
documentation and test suite cleanup done by me (gregory.p.smith).
Fixes issue 815646 and 595601 (as well as many other bugs and
references to this problem dating back to the dawn of Python).
Add enough debugging information to diagnose failures where the
HandlerBException is ignored, and fix one such problem, where it was thrown
during the __del__ method of the previous Popen object.
We may want to find a better way of printing verbose information so it's not
spammy when the test passes.
Mark Hammond [Sun, 6 Apr 2008 01:42:06 +0000 (01:42 +0000)]
From issue 1753245 - better _winreg support for x64.
Adds _winreg.DisableReflectionKey, EnableReflectionKey, QueryReflectionKey,
KEY_WOW64_64KEY and KEY_WOW64_32KEY.
Thomas Wouters [Sat, 5 Apr 2008 23:39:15 +0000 (23:39 +0000)]
Fix test_distutils to not fail when running 'make test' from a Python build
directory that is not the source directory (ie, one created using
'/path/to/source/configure'.) Leaves this test very slightly degraded in
that particular case, compared to the build-in-sourcedir case, but that case
isn't a particularly strong test either: neither test the actual path that
will be used after installing. There isn't a particularly good way to test
this, and a poor test beats a failing test.
Prevent test_sqlite from hanging on older versions of sqlite.
The problem is that when trying to do the second insert, sqlite seems to sleep
for a very long time. Here is the output from strace:
Trent Nelson [Fri, 4 Apr 2008 20:04:09 +0000 (20:04 +0000)]
Revert r62152 (Issue #2550). Being able to observe the results of all the buildbots was certainly useful. All of the platforms that have some form of BSD lineage -- FreeBSD, OS X, Solaris and Tru64 -- all pass the test. Windows and Linux, on the other hand, don't. Windows I knew about, Linux was a surprise. Knowing this, I believe a more appropriate fix will revolve around test_support.bind_socket() -- this method needs to return a port that nothing in the system has bound already. The best way to do this may just be to rely on ephemeral ports, rather than having the user specify a desired port, then fall back to four random ports, then try 0.
Trent Nelson [Fri, 4 Apr 2008 17:26:21 +0000 (17:26 +0000)]
Issue 2550: extend test_socket.py to test SO_REUSEADDR semantics when bind() is called on identical (host, port) combinations in two separate sockets. This should raise an EADDRINUSE socket.error in all cases, irrespective of whether or not SO_REUSEADDR is set on the sockets. However, with Windows, when SO_REUSEADDR is set on the sockets, no error is thrown (an error is thrown when the option isn't set), which results in an extremely wedged python process whenever accept() is called on either of the bound sockets. I'm committing this test now to observe if it's only Windows that has this behaviour (via the buildbots). Note: this WILL break all Windows buildbots for now; once I've observed the results on other platforms, I'll revert, then start looking into a patch.
Fred Drake [Fri, 4 Apr 2008 11:31:14 +0000 (11:31 +0000)]
my previous change did what I said it should not: it changed the current
directory to the directory in which the setup.py script lived (which made
__file__ wrong)
fixed, with test that the script is run in the current directory of the caller
Fred Drake [Fri, 4 Apr 2008 05:41:30 +0000 (05:41 +0000)]
- Issue #2385: distutils.core.run_script() makes __file__ available, so the
controlled environment will more closely mirror the typical script
environment. This supports setup.py scripts that refer to data files.
Trent Nelson [Thu, 3 Apr 2008 20:00:08 +0000 (20:00 +0000)]
Make kill_python a little more forgiving if it can't obtain a snapshot of module information for a given python[_d].exe process. Failing here was too pessimistic; the python[_d].exe process may be owned by another user, which is the case in some buildbot environments.
Trent Nelson [Thu, 3 Apr 2008 18:27:06 +0000 (18:27 +0000)]
Reimplement kill_python. The existing version had a number of flaws, namely, it didn't work for x64 and it wasn't precise about which python_d.exe it was killing -- it just killed the first one it came across that happened to have 'pcbuild\python_d.exe' or 'build\python_d.exe' in it's path. The new version has been rewritten from the ground up and now lives in PCbuild, instead of Tools\buildbot, and it has also been incorporated into the Visual Studio solution (pcbuild.sln) as 'kill_python'. The solution has also been altered such that kill_python is called where necessary in the build process in order to prevent any linking errors due to open file locks. In lieu of this, all of the existing bits and pieces in Tools\buildbot that called out to kill_python at various points have also been removed as they are now obsolete. Tested on both Win32 and x64.
Change set (included to improve usefulness of svnmerge log entry):
M PCbuild\pythoncore.vcproj
M PCbuild\pcbuild.sln
M PCbuild\release.vsprops
A PCbuild\kill_python.vcproj
M PCbuild\debug.vsprops
A PCbuild\kill_python.c
D Tools\buildbot\kill_python.bat
D Tools\buildbot\kill_python.mak
M Tools\buildbot\build.bat
D Tools\buildbot\Makefile
M Tools\buildbot\build-amd64.bat
M Tools\buildbot\buildmsi.bat
D Tools\buildbot\kill_python.c
Fix: #2315, #2316, #2317: TimedRotatingFileHandler - changed logic to better handle daylight savings time, deletion of old log files, and fixed a bug in calculating rollover when no logging occurs for a longer interval than the rollover period.
Trent Nelson [Wed, 2 Apr 2008 15:01:00 +0000 (15:01 +0000)]
Update information pertaining to building external components, as well as notes on x64 builds. This file now accurately describes the build process as is; however, there's still a lot of room for improvement, especially with regards to how we build Tcl/Tk, Tix, and OpenSSL. Watch this space for further improvements.
Correct the apparent refleak in test_io:
When cls is an ABCMeta, every call to isinstance(x, cls)
records type(x) in the cls._abc_cache of cls_abc_negative_cache.
So we clear these caches at the end of the test.
inspect.isabstract() is not the correct test for all ABCs, because there is no @abstractmethod in io.py (why?)
isinstance(cls, ABCMeta) would be more exact, but it fails with an infinite recursion.
So I used a hack to determine whether a class is an ABCMeta.
The true correction would be to turn cls._abc_cache &co into a WeakSet, as py3k does.
But classic classes are not weak referenceable...
Of course, this change should not be merged into the py3k branch.
Be sure to close the file. 2 places were deleting the file, so it was probably
fine, but the last change may be required for the test to pass on Windows.
Should we always close the mmap too?