suite as a side-effect of importing the module.
- in test_capi, a thread tried to import other modules
- re.compile() imported sre_parse again on every call.
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).
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.
calls threading.currentThread.
The correction somewhat improves the code, but it was close.
Many thanks to the "with" construct, which turns python code into C calls.
I wonder if it is not better to sys.settrace(None) just after
running the __main__ module and before finalization.
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.
The moved tests use a local server rather than going out to external servers.
Accepts patch from issue2429.
Contributed by Jerry Seutter & Michael Foord (fuzzyman) at PyCon 2008.
reliable, but I'm not convinced it is the right solution. We need
to determine if this causes the test to hang on any platforms or do
other bad things.
Even if it gets the test to pass reliably, it might be that we want
to fix this in socket. The socket returned from accept() is different
on different platforms (inheriting attributes or not) and we might
want to ensure that the attributes (at least blocking) is the same
across all platforms.
up after it was joined had a traceback pointing to that thread's (deleted)
target attribute, while the test was trying to check that the target was
destroyed. Big thanks to Antoine Pitrou for diagnosing the race and pointing
out sys.exc_clear() to kill the exception early. This fixes issue 2496.
svn+ssh://pythondev@svn.python.org/python/branches/trunk-bytearray
........
r61750 | christian.heimes | 2008-03-22 20:47:44 +0100 (Sat, 22 Mar 2008) | 1 line
Copied files from py3k w/o modifications
........
r61752 | christian.heimes | 2008-03-22 20:53:20 +0100 (Sat, 22 Mar 2008) | 7 lines
Take One
* Added initialization code, warnings, flags etc. to the appropriate places
* Added new buffer interface to string type
* Modified tests
* Modified Makefile.pre.in to compile the new files
* Added bytesobject.c to Python.h
........
r61754 | christian.heimes | 2008-03-22 21:22:19 +0100 (Sat, 22 Mar 2008) | 2 lines
Disabled bytearray.extend for now since it causes an infinite recursion
Fixed serveral unit tests
........
r61756 | christian.heimes | 2008-03-22 21:43:38 +0100 (Sat, 22 Mar 2008) | 5 lines
Added PyBytes support to several places:
str + bytearray
ord(bytearray)
bytearray(str, encoding)
........
r61760 | christian.heimes | 2008-03-22 21:56:32 +0100 (Sat, 22 Mar 2008) | 1 line
Fixed more unit tests related to type('') is not unicode
........
r61763 | christian.heimes | 2008-03-22 22:20:28 +0100 (Sat, 22 Mar 2008) | 2 lines
Fixed more unit tests
Fixed bytearray.extend
........
r61768 | christian.heimes | 2008-03-22 22:40:50 +0100 (Sat, 22 Mar 2008) | 1 line
Implemented old buffer interface for bytearray
........
r61772 | christian.heimes | 2008-03-22 23:24:52 +0100 (Sat, 22 Mar 2008) | 1 line
Added backport of the io module
........
r61775 | christian.heimes | 2008-03-23 03:50:49 +0100 (Sun, 23 Mar 2008) | 1 line
Fix str assignement to bytearray. Assignment of a str of size 1 is interpreted as a single byte
........
r61805 | christian.heimes | 2008-03-23 19:33:48 +0100 (Sun, 23 Mar 2008) | 3 lines
Fixed more tests
Fixed bytearray() comparsion with unicode()
Fixed iterator assignment of bytearray
........
r61809 | christian.heimes | 2008-03-23 21:02:21 +0100 (Sun, 23 Mar 2008) | 2 lines
str(bytesarray()) now returns the bytes and not the representation of the bytearray object
Enabled and fixed more unit tests
........
r61812 | christian.heimes | 2008-03-23 21:53:08 +0100 (Sun, 23 Mar 2008) | 3 lines
Clear error PyNumber_AsSsize_t() fails
Use CHARMASK for ob_svall access
disabled a test with memoryview again
........
r61819 | christian.heimes | 2008-03-23 23:05:57 +0100 (Sun, 23 Mar 2008) | 1 line
Untested updates to the PCBuild directory
........
r61917 | christian.heimes | 2008-03-26 00:57:06 +0100 (Wed, 26 Mar 2008) | 1 line
The type system of Python 2.6 has subtle differences to 3.0's. I've removed the Py_TPFLAGS_BASETYPE flags from bytearray for now. bytearray can't be subclasses until the issues with bytearray subclasses are fixed.
........
r61920 | christian.heimes | 2008-03-26 01:44:08 +0100 (Wed, 26 Mar 2008) | 2 lines
Disabled last failing test
I don't understand what the test is testing and how it suppose to work. Ka-Ping, please check it out.
........
r61930 | christian.heimes | 2008-03-26 12:46:18 +0100 (Wed, 26 Mar 2008) | 1 line
Re-enabled bytes warning code
........
r61933 | christian.heimes | 2008-03-26 13:20:46 +0100 (Wed, 26 Mar 2008) | 1 line
Fixed a bug in the new buffer protocol. The buffer slots weren't copied into a subclass.
........
r61934 | christian.heimes | 2008-03-26 13:25:09 +0100 (Wed, 26 Mar 2008) | 1 line
Re-enabled bytearray subclassing - all tests are passing.
........
an open file. This doesn't seem to be a problem in 2.6, but that appears
to be somewhat accidental (specific to reference counting). When this
gets merged to 3.0, it will make the 3.0 code simpler.
the connect would succeed before the timeout occurred. Try using an
address and port that hopefully doesn't exist to ensure we get no response.
If this doesn't work, we can use a public address close to python.org
and hopefully that address never gets taken.