works properly.
PyErr_SetFromErrnoWithFilenameObject() was already fixed by the changeset
793c75177d28. This commit fixes PyErr_SetExcFromWindowsErrWithFilenameObject(),
used on Windows.
svn+ssh://pythondev@svn.python.org/python/trunk
........
r77088 | georg.brandl | 2009-12-28 09:34:58 +0100 (Mo, 28 Dez 2009) | 1 line
#7033: add new API function PyErr_NewExceptionWithDoc, for easily giving new exceptions a docstring.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r72698 | hirokazu.yamamoto | 2009-05-17 11:52:09 +0900 | 1 line
Issue #3527: Removed Py_WIN_WIDE_FILENAMES which is not used any more.
........
r72699 | hirokazu.yamamoto | 2009-05-17 11:58:36 +0900 | 1 line
Added NEWS for r72698.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r71024 | georg.brandl | 2009-04-02 04:47:44 +0200 (Do, 02 Apr 2009) | 4 lines
In PyErr_GivenExceptionMatches, temporarily bump the recursion
limit, so that in the most common case PyObject_IsSubclass will
not raise a recursion error we have to ignore anyway.
........
r71058 | georg.brandl | 2009-04-02 20:09:04 +0200 (Do, 02 Apr 2009) | 3 lines
PyErr_NormalizeException may not set an error, so convert the PyErr_SetObject
call on hitting the recursion limit into just assigning it to the arguments provided.
........
an 'except' clause), the exception __context__ would be reset to None.
This crases the interpreter if this precisely happens inside PyErr_SetObject.
- now the __context__ is properly preserved
- in any case, PyErr_SetObject now saves the current exc_value in a local variable, to
avoid such crashes in the future.
Reviewer: Antoine Pitrou.
match Python 2.5 speed despite the __instancecheck__ / __subclasscheck__
mechanism. In the process, fix a bug where isinstance() and issubclass(),
when given a tuple of classes as second argument, were looking up
__instancecheck__ / __subclasscheck__ on the tuple rather than on each
type object.
Reviewed by Benjamin Peterson and Raymond Hettinger.
PyUnicode_AsStringAndSize -> _PyUnicode_AsStringAndSize to mark
them for interpreter internal use only.
We'll have to rework these APIs or create new ones for the
purpose of accessing the UTF-8 representation of Unicode objects
for 3.1.
