summaryrefslogtreecommitdiffstats
path: root/Include/unicodeobject.h
diff options
context:
space:
mode:
authorGuido van Rossum <guido@python.org>2001-10-19 02:01:31 (GMT)
committerGuido van Rossum <guido@python.org>2001-10-19 02:01:31 (GMT)
commitb8c65bc27ffc61c659180c351d3cc283abd1be45 (patch)
tree45f9f5c11d6ea41fa7e78aaab2b9531ec1f9cf92 /Include/unicodeobject.h
parent93505a2f2b468bed3ec2ba013f07ee063cf618e8 (diff)
downloadcpython-b8c65bc27ffc61c659180c351d3cc283abd1be45.zip
cpython-b8c65bc27ffc61c659180c351d3cc283abd1be45.tar.gz
cpython-b8c65bc27ffc61c659180c351d3cc283abd1be45.tar.bz2
SF patch #470578: Fixes to synchronize unicode() and str()
This patch implements what we have discussed on python-dev late in September: str(obj) and unicode(obj) should behave similar, while the old behaviour is retained for unicode(obj, encoding, errors). The patch also adds a new feature with which objects can provide unicode(obj) with input data: the __unicode__ method. Currently no new tp_unicode slot is implemented; this is left as option for the future. Note that PyUnicode_FromEncodedObject() no longer accepts Unicode objects as input. The API name already suggests that Unicode objects do not belong in the list of acceptable objects and the functionality was only needed because PyUnicode_FromEncodedObject() was being used directly by unicode(). The latter was changed in the discussed way: * unicode(obj) calls PyObject_Unicode() * unicode(obj, encoding, errors) calls PyUnicode_FromEncodedObject() One thing left open to discussion is whether to leave the PyUnicode_FromObject() API as a thin API extension on top of PyUnicode_FromEncodedObject() or to turn it into a (macro) alias for PyObject_Unicode() and deprecate it. Doing so would have some surprising consequences though, e.g. u"abc" + 123 would turn out as u"abc123"... [Marc-Andre didn't have time to check this in before the deadline. I hope this is OK, Marc-Andre! You can still make changes and commit them on the trunk after the branch has been made, but then please mail Barry a context diff if you want the change to be merged into the 2.2b1 release branch. GvR]
Diffstat (limited to 'Include/unicodeobject.h')
-rw-r--r--Include/unicodeobject.h19
1 files changed, 9 insertions, 10 deletions
diff --git a/Include/unicodeobject.h b/Include/unicodeobject.h
index 41feae2..368a212 100644
--- a/Include/unicodeobject.h
+++ b/Include/unicodeobject.h
@@ -454,14 +454,12 @@ extern DL_IMPORT(int) PyUnicode_Resize(
Coercion is done in the following way:
- 1. Unicode objects are passed back as-is with incremented
- refcount.
-
- 2. String and other char buffer compatible objects are decoded
+ 1. String and other char buffer compatible objects are decoded
under the assumptions that they contain data using the current
default encoding. Decoding is done in "strict" mode.
- 3. All other objects raise an exception.
+ 2. All other objects (including Unicode objects) raise an
+ exception.
The API returns NULL in case of an error. The caller is responsible
for decref'ing the returned objects.
@@ -474,12 +472,13 @@ extern DL_IMPORT(PyObject*) PyUnicode_FromEncodedObject(
const char *errors /* error handling */
);
-/* Shortcut for PyUnicode_FromEncodedObject(obj, NULL, "strict");
- which results in using the default encoding as basis for
- decoding the object.
-
- Coerces obj to an Unicode object and return a reference with
+/* Coerce obj to an Unicode object and return a reference with
*incremented* refcount.
+
+ Unicode objects are passed back as-is (subclasses are converted to
+ true Unicode objects), all other objects are delegated to
+ PyUnicode_FromEncodedObject(obj, NULL, "strict") which results in
+ using the default encoding as basis for decoding the object.
The API returns NULL in case of an error. The caller is responsible
for decref'ing the returned objects.