1. 24 Agu, 2001 1 kayıt (commit)
  2. 13 May, 2001 1 kayıt (commit)
    • Tim Peters's avatar
      Get rid of the superstitious "~" in dict hashing's "i = (~hash) & mask". · 2f228e75
      Tim Peters yazdı
      The comment following used to say:
      	/* We use ~hash instead of hash, as degenerate hash functions, such
      	   as for ints <sigh>, can have lots of leading zeros. It's not
      	   really a performance risk, but better safe than sorry.
      	   12-Dec-00 tim:  so ~hash produces lots of leading ones instead --
      	   what's the gain? */
      That is, there was never a good reason for doing it.  And to the contrary,
      as explained on Python-Dev last December, it tended to make the *sum*
      (i + incr) & mask (which is the first table index examined in case of
      collison) the same "too often" across distinct hashes.
      
      Changing to the simpler "i = hash & mask" reduced the number of string-dict
      collisions (== # number of times we go around the lookup for-loop) from about
      6 million to 5 million during a full run of the test suite (these are
      approximate because the test suite does some random stuff from run to run).
      The number of collisions in non-string dicts also decreased, but not as
      dramatically.
      
      Note that this may, for a given dict, change the order (wrt previous
      releases) of entries exposed by .keys(), .values() and .items().  A number
      of std tests suffered bogus failures as a result.  For dicts keyed by
      small ints, or (less so) by characters, the order is much more likely to be
      in increasing order of key now; e.g.,
      
      >>> d = {}
      >>> for i in range(10):
      ...    d[i] = i
      ...
      >>> d
      {0: 0, 1: 1, 2: 2, 3: 3, 4: 4, 5: 5, 6: 6, 7: 7, 8: 8, 9: 9}
      >>>
      
      Unfortunately. people may latch on to that in small examples and draw a
      bogus conclusion.
      
      test_support.py
          Moved test_extcall's sortdict() into test_support, made it stronger,
          and imported sortdict into other std tests that needed it.
      test_unicode.py
          Excluced cp875 from the "roundtrip over range(128)" test, because
          cp875 doesn't have a well-defined inverse for unicode("?", "cp875").
          See Python-Dev for excruciating details.
      Cookie.py
          Chaged various output functions to sort dicts before building
          strings from them.
      test_extcall
          Fiddled the expected-result file.  This remains sensitive to native
          dict ordering, because, e.g., if there are multiple errors in a
          keyword-arg dict (and test_extcall sets up many cases like that), the
          specific error Python complains about first depends on native dict
          ordering.
      2f228e75
  3. 05 May, 2001 1 kayıt (commit)
    • Tim Peters's avatar
      Generalize tuple() to work nicely with iterators. · 6912d4dd
      Tim Peters yazdı
      NEEDS DOC CHANGES.
      This one surprised me!  While I expected tuple() to be a no-brainer, turns
      out it's actually dripping with consequences:
      1. It will *allow* the popular PySequence_Fast() to work with any iterable
         object (code for that not yet checked in, but should be trivial).
      2. It caused two std tests to fail.  This because some places used
         PyTuple_Sequence() (the C spelling of tuple()) as an indirect way to test
         whether something *is* a sequence.  But tuple() code only looked for the
         existence of sq->item to determine that, and e.g. an instance passed
         that test whether or not it supported the other operations tuple()
         needed (e.g., __len__).  So some things the tests *expected* to fail
         with an AttributeError now fail with a TypeError instead.  This looks
         like an improvement to me; e.g., test_coercion used to produce 559
         TypeErrors and 2 AttributeErrors, and now they're all TypeErrors.  The
         error details are more informative too, because the places calling this
         were *looking* for TypeErrors in order to replace the generic tuple()
         "not a sequence" msg with their own more specific text, and
         AttributeErrors snuck by that.
      6912d4dd
  4. 11 Nis, 2001 1 kayıt (commit)
  5. 09 Şub, 2001 1 kayıt (commit)
  6. 21 Ock, 2001 1 kayıt (commit)
  7. 17 Ock, 2001 2 kayıt (commit)
  8. 15 Ock, 2001 1 kayıt (commit)
  9. 04 Ock, 2001 1 kayıt (commit)
    • Fred Drake's avatar
      When a PyCFunction that takes only positional parameters is called with · 1a7aab70
      Fred Drake yazdı
      an empty keywords dictionary (via apply() or the extended call syntax),
      the keywords dict should be ignored.  If the keywords dict is not empty,
      TypeError should be raised.  (Between the restructuring of the call
      machinery and this patch, an empty dict in this situation would trigger
      a SystemError via PyErr_BadInternalCall().)
      
      Added regression tests to detect errors for this.
      1a7aab70
  10. 30 Eki, 2000 1 kayıt (commit)
    • Jeremy Hylton's avatar
      Fix for SF bug #117241 · 6b4ec513
      Jeremy Hylton yazdı
      When a method is called with no regular arguments and * args, defer
      the first arg is subclass check until after the * args have been
      expanded.
      
      N.B. The CALL_FUNCTION implementation is getting really hairy; should
      review it to see if it can be simplified.
      6b4ec513
  11. 23 Eki, 2000 1 kayıt (commit)
  12. 15 Tem, 2000 1 kayıt (commit)
  13. 10 Nis, 2000 1 kayıt (commit)
  14. 30 Mar, 2000 1 kayıt (commit)
    • Jeremy Hylton's avatar
      Two fixes for extended call syntax: · 074c3e62
      Jeremy Hylton yazdı
      If a non-tuple sequence is passed as the *arg, convert it to a tuple
      before checking its length.
      If named keyword arguments are used in combination with **kwargs, make
      a copy of kwargs before inserting the new keys.
      074c3e62
  15. 28 Mar, 2000 2 kayıt (commit)