diff options
author | Guido van Rossum <guido@python.org> | 2000-04-05 20:11:21 (GMT) |
---|---|---|
committer | Guido van Rossum <guido@python.org> | 2000-04-05 20:11:21 (GMT) |
commit | 9e896b37c7a554250d7d832566cc4fe7d30d034c (patch) | |
tree | 58692393b51a2102b34f01a01184b6b1e77ea530 /Objects/floatobject.c | |
parent | 457855a5f03ce6637e5ab807deec6331ddab2059 (diff) | |
download | cpython-9e896b37c7a554250d7d832566cc4fe7d30d034c.zip cpython-9e896b37c7a554250d7d832566cc4fe7d30d034c.tar.gz cpython-9e896b37c7a554250d7d832566cc4fe7d30d034c.tar.bz2 |
Marc-Andre's third try at this bulk patch seems to work (except that
his copy of test_contains.py seems to be broken -- the lines he
deleted were already absent). Checkin messages:
New Unicode support for int(), float(), complex() and long().
- new APIs PyInt_FromUnicode() and PyLong_FromUnicode()
- added support for Unicode to PyFloat_FromString()
- new encoding API PyUnicode_EncodeDecimal() which converts
Unicode to a decimal char* string (used in the above new
APIs)
- shortcuts for calls like int(<int object>) and float(<float obj>)
- tests for all of the above
Unicode compares and contains checks:
- comparing Unicode and non-string types now works; TypeErrors
are masked, all other errors such as ValueError during
Unicode coercion are passed through (note that PyUnicode_Compare
does not implement the masking -- PyObject_Compare does this)
- contains now works for non-string types too; TypeErrors are
masked and 0 returned; all other errors are passed through
Better testing support for the standard codecs.
Misc minor enhancements, such as an alias dbcs for the mbcs codec.
Changes:
- PyLong_FromString() now applies the same error checks as
does PyInt_FromString(): trailing garbage is reported
as error and not longer silently ignored. The only characters
which may be trailing the digits are 'L' and 'l' -- these
are still silently ignored.
- string.ato?() now directly interface to int(), long() and
float(). The error strings are now a little different, but
the type still remains the same. These functions are now
ready to get declared obsolete ;-)
- PyNumber_Int() now also does a check for embedded NULL chars
in the input string; PyNumber_Long() already did this (and
still does)
Followed by:
Looks like I've gone a step too far there... (and test_contains.py
seem to have a bug too).
I've changed back to reporting all errors in PyUnicode_Contains()
and added a few more test cases to test_contains.py (plus corrected
the join() NameError).
Diffstat (limited to 'Objects/floatobject.c')
-rw-r--r-- | Objects/floatobject.c | 16 |
1 files changed, 16 insertions, 0 deletions
diff --git a/Objects/floatobject.c b/Objects/floatobject.c index fb1acdc..77ef8d0 100644 --- a/Objects/floatobject.c +++ b/Objects/floatobject.c @@ -164,6 +164,22 @@ PyFloat_FromString(v, pend) s = PyString_AS_STRING(v); len = PyString_GET_SIZE(v); } + else if (PyUnicode_Check(v)) { + char s_buffer[256]; + + if (PyUnicode_GET_SIZE(v) >= sizeof(s_buffer)) { + PyErr_SetString(PyExc_ValueError, + "float() literal too large to convert"); + return NULL; + } + if (PyUnicode_EncodeDecimal(PyUnicode_AS_UNICODE(v), + PyUnicode_GET_SIZE(v), + s_buffer, + NULL)) + return NULL; + s = s_buffer; + len = strlen(s); + } else if (PyObject_AsCharBuffer(v, &s, &len)) { PyErr_SetString(PyExc_TypeError, "float() needs a string argument"); |