1. 01 Şub, 2001 1 kayıt (commit)
  2. 17 Ock, 2001 1 kayıt (commit)
  3. 08 Ock, 2001 1 kayıt (commit)
  4. 04 Ock, 2001 1 kayıt (commit)
  5. 24 Eki, 2000 1 kayıt (commit)
    • Fred Drake's avatar
      Ka-Ping Yee <ping@lfw.org>: · 661ea26b
      Fred Drake yazdı
      Changes to error messages to increase consistency & clarity.
      
      This (mostly) closes SourceForge patch #101839.
      661ea26b
  6. 06 Eki, 2000 1 kayıt (commit)
    • Tim Peters's avatar
      SF bug 115831 and Ping's SF patch 101751, 0.0**-2.0 returns inf rather than · c54d1904
      Tim Peters yazdı
      raise ValueError.  Checked in the patch as far as it went, but also changed
      all of ints, longs and floats to raise ZeroDivisionError instead when raising
      0 to a negative number.  This is what 754-inspired stds require, as the "true
      result" is an infinity obtained from finite operands, i.e. it's a singularity.
      Also changed float pow to not be so timid about using its square-and-multiply
      algorithm.  Note that what math.pow does is unrelated to what builtin pow
      does, and will still vary by platform.
      c54d1904
  7. 26 Eyl, 2000 1 kayıt (commit)
  8. 25 Eyl, 2000 1 kayıt (commit)
  9. 23 Eyl, 2000 1 kayıt (commit)
    • Tim Peters's avatar
      Fix for SF bug 110624: float literals behave inconsistently. · ef14d73b
      Tim Peters yazdı
      I fixed the specific complaint but left the (many) large issues untouched.
      See the (very long) bug report discussion for why:
          http://sourceforge.net/bugs/?func=detailbug&group_id=5470&bug_id=110624
      Note that while I left the interface to the undocumented public API function
      PyFloat_FromString alone, its 2nd argument is useless.  From a comment block
      in the code:
      
      RED_FLAG 22-Sep-2000 tim
      PyFloat_FromString's pend argument is braindead.  Prior to this RED_FLAG,
      
      1.  If v was a regular string, *pend was set to point to its terminating
          null byte.  That's useless (the caller can find that without any
          help from this function!).
      
      2.  If v was a Unicode string, or an object convertible to a character
          buffer, *pend was set to point into stack trash (the auto temp
          vector holding the character buffer).  That was downright dangerous.
      
      Since we can't change the interface of a public API function, pend is
      still supported but now *officially* useless:  if pend is not NULL,
      *pend is set to NULL.
      ef14d73b
  10. 16 Eyl, 2000 1 kayıt (commit)
  11. 01 Eyl, 2000 1 kayıt (commit)
  12. 18 Agu, 2000 1 kayıt (commit)
  13. 15 Agu, 2000 1 kayıt (commit)
    • Tim Peters's avatar
      Fix for http://sourceforge.net/bugs/?func=detailbug&bug_id=111866&group_id=5470. · 39dce293
      Tim Peters yazdı
      This was a misleading bug -- the true "bug" was that hash(x) gave an error
      return when x is an infinity.  Fixed that.  Added new Py_IS_INFINITY macro to
      pyport.h.  Rearranged code to reduce growing duplication in hashing of float and
      complex numbers, pushing Trent's earlier stab at that to a logical conclusion.
      Fixed exceedingly rare bug where hashing of floats could return -1 even if there
      wasn't an error (didn't waste time trying to construct a test case, it was simply
      obvious from the code that it *could* happen).  Improved complex hash so that
      hash(complex(x, y)) doesn't systematically equal hash(complex(y, x)) anymore.
      39dce293
  14. 12 Agu, 2000 1 kayıt (commit)
  15. 31 Tem, 2000 1 kayıt (commit)
  16. 09 Tem, 2000 3 kayıt (commit)
  17. 30 Haz, 2000 3 kayıt (commit)
    • Guido van Rossum's avatar
      Change copyright notice - 2nd try. · ffcc3813
      Guido van Rossum yazdı
      ffcc3813
    • Guido van Rossum's avatar
      Change copyright notice. · fd71b9e9
      Guido van Rossum yazdı
      fd71b9e9
    • Fred Drake's avatar
      Trent Mick <trentm@activestate.com>: · a44d353e
      Fred Drake yazdı
      The common technique for printing out a pointer has been to cast to a long
      and use the "%lx" printf modifier. This is incorrect on Win64 where casting
      to a long truncates the pointer. The "%p" formatter should be used instead.
      
      The problem as stated by Tim:
      > Unfortunately, the C committee refused to define what %p conversion "looks
      > like" -- they explicitly allowed it to be implementation-defined. Older
      > versions of Microsoft C even stuck a colon in the middle of the address (in
      > the days of segment+offset addressing)!
      
      The result is that the hex value of a pointer will maybe/maybe not have a 0x
      prepended to it.
      
      
      Notes on the patch:
      
      There are two main classes of changes:
      - in the various repr() functions that print out pointers
      - debugging printf's in the various thread_*.h files (these are why the
      patch is large)
      
      
      Closes SourceForge patch #100505.
      a44d353e
  18. 29 Haz, 2000 1 kayıt (commit)
    • Fred Drake's avatar
      This patch addresses two main issues: (1) There exist some non-fatal · 13634cf7
      Fred Drake yazdı
      errors in some of the hash algorithms. For exmaple, in float_hash and
      complex_hash a certain part of the value is not included in the hash
      calculation. See Tim's, Guido's, and my discussion of this on
      python-dev in May under the title "fix float_hash and complex_hash for
      64-bit *nix"
      
      (2) The hash algorithms that use pointers (e.g. func_hash, code_hash)
      are universally not correct on Win64 (they assume that sizeof(long) ==
      sizeof(void*))
      
      As well, this patch significantly cleans up the hash code. It adds the
      two function _Py_HashDouble and _PyHash_VoidPtr that the various
      hashing routine are changed to use.
      
      These help maintain the hash function invariant: (a==b) =>
      (hash(a)==hash(b))) I have added Lib/test/test_hash.py and
      Lib/test/output/test_hash to test this for some cases.
      13634cf7
  19. 03 May, 2000 1 kayıt (commit)
    • Guido van Rossum's avatar
      Vladimir Marangozov's long-awaited malloc restructuring. · b18618da
      Guido van Rossum yazdı
      For more comments, read the patches@python.org archives.
      For documentation read the comments in mymalloc.h and objimpl.h.
      
      (This is not exactly what Vladimir posted to the patches list; I've
      made a few changes, and Vladimir sent me a fix in private email for a
      problem that only occurs in debug mode.  I'm also holding back on his
      change to main.c, which seems unnecessary to me.)
      b18618da
  20. 05 Nis, 2000 1 kayıt (commit)
    • Guido van Rossum's avatar
      Marc-Andre's third try at this bulk patch seems to work (except that · 9e896b37
      Guido van Rossum yazdı
      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
  21. 10 Mar, 2000 1 kayıt (commit)
  22. 20 Ock, 2000 1 kayıt (commit)
  23. 23 Ara, 1999 1 kayıt (commit)
  24. 12 Eki, 1999 1 kayıt (commit)
  25. 06 May, 1999 1 kayıt (commit)
    • Guido van Rossum's avatar
      Tim Peters writes: · 9263e78f
      Guido van Rossum yazdı
      1. Fixes float divmod so that the quotient it returns is always an integral
      value.
      
      2. Fixes float % and float divmod so that the remainder always gets the
      right sign (the current code uses a "are the signs different?" test that
      doesn't work half the time <wink> when the product of the divisor and the
      remainder underflows to 0).
      9263e78f
  26. 19 Mar, 1999 1 kayıt (commit)
  27. 12 Mar, 1999 2 kayıt (commit)
  28. 11 Mar, 1999 1 kayıt (commit)
  29. 10 Mar, 1999 1 kayıt (commit)
  30. 31 Eki, 1997 1 kayıt (commit)
  31. 05 Agu, 1997 1 kayıt (commit)
  32. 13 May, 1997 1 kayıt (commit)
  33. 02 May, 1997 1 kayıt (commit)
  34. 14 Mar, 1997 1 kayıt (commit)
  35. 14 Şub, 1997 1 kayıt (commit)