1. 18 Apr, 2001 13 commits
  2. 17 Apr, 2001 1 commit
  3. 16 Apr, 2001 19 commits
  4. 15 Apr, 2001 7 commits
    • Guido van Rossum's avatar
      Tentative fix for a problem that Tim discovered at the last moment, · a4dd0112
      Guido van Rossum authored
      and reported to python-dev: because we were calling dict_resize() in
      PyDict_Next(), and because GC's dict_traverse() uses PyDict_Next(),
      and because PyTuple_New() can cause GC, and because dict_items() calls
      PyTuple_New(), it was possible for dict_items() to have the dict
      resized right under its nose.
      
      The solution is convoluted, and touches several places: keys(),
      values(), items(), popitem(), PyDict_Next(), and PyDict_SetItem().
      
      There are two parts to it. First, we no longer call dict_resize() in
      PyDict_Next(), which seems to solve the immediate problem.  But then
      PyDict_SetItem() must have a different policy about when *it* calls
      dict_resize(), because we want to guarantee (e.g. for an algorithm
      that Jeremy uses in the compiler) that you can loop over a dict using
      PyDict_Next() and make changes to the dict as long as those changes
      are only value replacements for existing keys using PyDict_SetItem().
      This is done by resizing *after* the insertion instead of before, and
      by remembering the size before we insert the item, and if the size is
      still the same, we don't bother to even check if we might need to
      resize.  An additional detail is that if the dict starts out empty, we
      must still resize it before the insertion.
      
      That was the first part. :-)
      
      The second part is to make keys(), values(), items(), and popitem()
      safe against side effects on the dict caused by allocations, under the
      assumption that if the GC can cause arbitrary Python code to run, it
      can cause other threads to run, and it's not inconceivable that our
      dict could be resized -- it would be insane to write code that relies
      on this, but not all code is sane.
      
      Now, I have this nagging feeling that the loops in lookdict probably
      are blissfully assuming that doing a simple key comparison does not
      change the dict's size.  This is not necessarily true (the keys could
      be class instances after all).  But that's a battle for another day.
      a4dd0112
    • Guido van Rossum's avatar
      SF bug reporters. · 0aa30b00
      Guido van Rossum authored
      0aa30b00
    • Guido van Rossum's avatar
      Fix SF bug [ #416231 ] urllib.basejoin fails to apply some ../. · b8bf3bec
      Guido van Rossum authored
      Reported by Juan M. Bello Rivas.
      b8bf3bec
    • Fredrik Lundh's avatar
      9c7eab82
    • Guido van Rossum's avatar
      Patch by Mark Favas to ensure that the zlib we find is 1.1.3 or · e697091c
      Guido van Rossum authored
      later.  This assumes that zlib.h has a line of the form
      
          #define ZLIB_VERSION "1.1.3"
      
      This solves the problem where a zlib installation is found but it is
      an older version -- this would break the build, while a better
      solution is to simply ignore that zlib installation.
      e697091c
    • Guido van Rossum's avatar
      Get rid of the seek() method on the _Mailbox class. This was a · 2b5ff073
      Guido van Rossum authored
      cut-and-paste copy of the seek() method on the _Subfile class, but it
      didn't make one bit of sense: it sets self.pos, which is not used in
      this class or its subclasses, and it uses self.start and self.stop,
      which aren't defined on this class or its subclasses.  This is purely
      my own fault -- I added this in rev 1.4 and apparently never tried to
      use it.  Since it's not documented, and of very questionable use given
      that there's no tell(), I'm ripping it out.
      
      This resolves SF bug 416199 by Andrew Dalke: mailbox.py seek problems.
      2b5ff073
    • Guido van Rossum's avatar
      In order to make this test work on Windows, the test locale has to be · fc349862
      Guido van Rossum authored
      set to 'en' there -- Windows does not understand the 'en_US' locale.
      The test succeeds there.
      fc349862