1. 03 Jun, 2002 1 commit
    • Walter Dörwald's avatar
      Remove uses of the string and types modules: · 65230a2d
      Walter Dörwald authored
      x in string.whitespace => x.isspace()
      type(x) in types.StringTypes => isinstance(x, basestring)
      isinstance(x, types.StringTypes) => isinstance(x, basestring)
      type(x) is types.StringType => isinstance(x, str)
      type(x) == types.StringType => isinstance(x, str)
      string.split(x, ...) => x.split(...)
      string.join(x, y) => y.join(x)
      string.zfill(x, ...) => x.zfill(...)
      string.count(x, ...) => x.count(...)
      hasattr(types, "UnicodeType") => try: unicode except NameError:
      type(x) != types.TupleTuple => not isinstance(x, tuple)
      isinstance(x, types.TupleType) => isinstance(x, tuple)
      type(x) is types.IntType => isinstance(x, int)
      
      Do not mention the string module in the rlcompleter docstring.
      
      This partially applies SF patch http://www.python.org/sf/562373
      (with basestring instead of string). (It excludes the changes to
      unittest.py and does not change the os.stat stuff.)
      65230a2d
  2. 15 Apr, 2002 1 commit
    • Walter Dörwald's avatar
      Apply the second version of SF patch http://www.python.org/sf/536241 · 068325ef
      Walter Dörwald authored
      Add a method zfill to str, unicode and UserString and change
      Lib/string.py accordingly.
      
      This activates the zfill version in unicodeobject.c that was
      commented out and implements the same in stringobject.c. It also
      adds the test for unicode support in Lib/string.py back in and
      uses repr() instead() of str() (as it was before Lib/string.py 1.62)
      068325ef
  3. 29 Mar, 2002 1 commit
    • Andrew M. Kuchling's avatar
      [Bug #536241] string.zfill() produces mangled output for a Unicode string. · 102d1208
      Andrew M. Kuchling authored
          Walter Doerwald provided a patch, which I've modified in two ways:
      
      1) (Uncontroversial) Removed code to make module work in earlier versions of
         Python without the unicode() built-in
      
      2) (Poss. controversial) Instead of making string.zfill take the repr()
         of non-string objects, take the str().
      
      Should a warning be added to this branch of the code so that the automatic
      str() can be deprecated?
      
      2.2.2 bugfix candidate, assuming the repr()->str() change is deemed OK.
      102d1208
  4. 30 Jan, 2002 1 commit
  5. 20 Jul, 2001 1 commit
  6. 18 Feb, 2001 1 commit
  7. 15 Feb, 2001 1 commit
    • Skip Montanaro's avatar
      bunch more __all__ lists · 0de65807
      Skip Montanaro authored
      also modified check_all function to suppress all warnings since they aren't
      relevant to what this test is doing (allows quiet checking of regsub, for
      instance)
      0de65807
  8. 09 Feb, 2001 2 commits
  9. 15 Jan, 2001 1 commit
  10. 19 Dec, 2000 1 commit
  11. 18 Sep, 2000 2 commits
  12. 16 Jul, 2000 1 commit
    • Thomas Wouters's avatar
      Spelling fixes supplied by Rob W. W. Hooft. All these are fixes in either · 7e474022
      Thomas Wouters authored
      comments, docstrings or error messages. I fixed two minor things in
      test_winreg.py ("didn't" -> "Didn't" and "Didnt" -> "Didn't").
      
      There is a minor style issue involved: Guido seems to have preferred English
      grammar (behaviour, honour) in a couple places. This patch changes that to
      American, which is the more prominent style in the source. I prefer English
      myself, so if English is preferred, I'd be happy to supply a patch myself ;)
      7e474022
  13. 03 Jul, 2000 1 commit
  14. 05 Apr, 2000 1 commit
    • Guido van Rossum's avatar
      Marc-Andre's third try at this bulk patch seems to work (except that · 9e896b37
      Guido van Rossum authored
      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).
      9e896b37
  15. 10 Mar, 2000 1 commit
  16. 10 Feb, 2000 1 commit
    • Fred Drake's avatar
      Detabify. · 857c4c36
      Fred Drake authored
      I ran "expand" instead of using Skip's patch, but it's all the same.
      857c4c36
  17. 04 Feb, 2000 1 commit
    • Guido van Rossum's avatar
      The third and final doc-string sweep by Ka-Ping Yee. · e7b146fb
      Guido van Rossum authored
      The attached patches update the standard library so that all modules
      have docstrings beginning with one-line summaries.
      
      A new docstring was added to formatter.  The docstring for os.py
      was updated to mention nt, os2, ce in addition to posix, dos, mac.
      e7b146fb
  18. 04 Nov, 1999 1 commit
  19. 12 Oct, 1999 1 commit
  20. 11 Oct, 1999 1 commit
  21. 20 Apr, 1998 1 commit
  22. 30 Mar, 1998 1 commit
  23. 26 Mar, 1998 1 commit
  24. 29 Dec, 1997 2 commits
  25. 10 Dec, 1997 2 commits
  26. 01 Dec, 1997 1 commit
    • Guido van Rossum's avatar
      In string.split(), honor maxsplit (if > 0). · 06ba34c5
      Guido van Rossum authored
      In string.splitfields(), ignore maxsplit if <= 0, rather than ignoring
      maxsplit=0 but effectively treating negative numbers the same as
      maxsplit=1.  Also made the test for maxsplit slightly more efficient
      (set it to the length of the string when <= 0 so the test for its
      presence can be omitted from the loop).
      06ba34c5
  27. 22 Oct, 1997 1 commit
  28. 20 Oct, 1997 1 commit
  29. 02 Apr, 1997 1 commit
    • Guido van Rossum's avatar
      Changed my mind on replace(). · 21aa0ef3
      Guido van Rossum authored
      It's now replace(str, old, new, maxsplit=0).
      Note new ordering of parameters (string first);
      this is more consistent with translate().
      21aa0ef3
  30. 25 Mar, 1997 1 commit
  31. 14 Mar, 1997 1 commit
  32. 26 Aug, 1996 1 commit
  33. 20 Aug, 1996 1 commit
  34. 08 Aug, 1996 1 commit
  35. 23 Jul, 1996 1 commit
  36. 11 Jun, 1996 1 commit