that the behaviour of Decimal doesn't change if/when re.UNICODE becomes
assumed in Python 3.0.
Also add a check that alternative Unicode digits (e.g. u'\N{FULLWIDTH
DIGIT ONE}') are *not* accepted in a numeric string.
* Deprecate urllib.urlopen() in favor of urllib2.urlopen() for 3.0.
* Update docs to mention split/rename of the module and deprecation of
urlopen().
Changes to lib2to3 are in a separate commit. Work is for issue #2885.
When a thread touches such an object for the first time, a new thread-local __dict__ is created,
and the __init__ method is run.
But a thread switch can occur here; if the other thread touches the same object, it installs another
__dict__; when the first thread resumes, it updates the dictionary of the second...
This is the deep cause of the failures in test_multiprocessing involving "managers" objects.
Backport of r64601.
svn+ssh://pythondev@svn.python.org/python/trunk
........
r64601 | amaury.forgeotdarc | 2008-06-30 17:42:40 -0500 (Mon, 30 Jun 2008) | 11 lines
#Issue3088 in-progress: Race condition with instances of classes derived from threading.local:
When a thread touches such an object for the first time, a new thread-local __dict__ is created,
and the __init__ method is run.
But a thread switch can occur here; if the other thread touches the same object, it installs another
__dict__; when the first thread resumes, it updates the dictionary of the second...
This is the deep cause of the failures in test_multiprocessing involving "managers" objects.
Also a 2.5 backport candidate.
........
When a thread touches such an object for the first time, a new thread-local __dict__ is created,
and the __init__ method is run.
But a thread switch can occur here; if the other thread touches the same object, it installs another
__dict__; when the first thread resumes, it updates the dictionary of the second...
This is the deep cause of the failures in test_multiprocessing involving "managers" objects.
Also a 2.5 backport candidate.
svn+ssh://pythondev@svn.python.org/python/trunk
........
r64549 | brett.cannon | 2008-06-26 17:31:13 -0700 (Thu, 26 Jun 2008) | 7 lines
warnings.warn_explicit() did not have the proper TypeErrors in place to prevent
bus errors or SystemError being raised. As a side effect of fixing this, a bad
DECREF that could be triggered when 'message' and 'category' were both None was
fixed.
Closes issue 3211. Thanks JP Calderone for the bug report.
........
bus errors or SystemError being raised. As a side effect of fixing this, a bad
DECREF that could be triggered when 'message' and 'category' were both None was
fixed.
Closes issue 3211. Thanks JP Calderone for the bug report.
behaviours. I left the original test commented out (note
that that test came from #2702, which seems to have a
problem in FreeBSD and Windows, but not in Linux).
I included a new test, to watch over the now-broken
behaviour, I took it from #3179.
