[Python-checkins] CVS: python/dist/src/Lib string.py,1.48,1.49

Guido van Rossum python-dev@python.org
Wed, 5 Apr 2000 16:11:51 -0400 (EDT)


Update of /projects/cvsroot/python/dist/src/Lib
In directory eric:/home/guido/hp/mal/py-patched/Lib

Modified Files:
	string.py 
Log Message:
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).



Index: string.py
===================================================================
RCS file: /projects/cvsroot/python/dist/src/Lib/string.py,v
retrieving revision 1.48
retrieving revision 1.49
diff -C2 -r1.48 -r1.49
*** string.py	2000/03/10 23:22:10	1.48
--- string.py	2000/04/05 20:11:18	1.49
***************
*** 197,208 ****
  
      """
!     if type(s) == _StringType:
!         return _float(s)
!     else:
!         raise TypeError('argument 1: expected string, %s found' %
!                         type(s).__name__)
  
  # Convert string to integer
! def atoi(*args):
      """atoi(s [,base]) -> int
  
--- 197,205 ----
  
      """
!     return _float(s)
  
+ 
  # Convert string to integer
! def atoi(s , base=10):
      """atoi(s [,base]) -> int
  
***************
*** 215,235 ****
  
      """
!     try:
!         s = args[0]
!     except IndexError:
!         raise TypeError('function requires at least 1 argument: %d given' %
!                         len(args))
!     # Don't catch type error resulting from too many arguments to int().  The
!     # error message isn't compatible but the error type is, and this function
!     # is complicated enough already.
!     if type(s) == _StringType:
!         return _apply(_int, args)
!     else:
!         raise TypeError('argument 1: expected string, %s found' %
!                         type(s).__name__)
  
  
  # Convert string to long integer
! def atol(*args):
      """atol(s [,base]) -> long
  
--- 212,220 ----
  
      """
!     return _int(s, base)
  
  
  # Convert string to long integer
! def atol(s, base=10):
      """atol(s [,base]) -> long
  
***************
*** 243,259 ****
  
      """
!     try:
!         s = args[0]
!     except IndexError:
!         raise TypeError('function requires at least 1 argument: %d given' %
!                         len(args))
!     # Don't catch type error resulting from too many arguments to long().  The
!     # error message isn't compatible but the error type is, and this function
!     # is complicated enough already.
!     if type(s) == _StringType:
!         return _apply(_long, args)
!     else:
!         raise TypeError('argument 1: expected string, %s found' %
!                         type(s).__name__)
  
  
--- 228,232 ----
  
      """
!     return _long(s, base)