1. 07 May, 2000 7 commits
  2. 06 May, 2000 6 commits
  3. 05 May, 2000 10 commits
  4. 04 May, 2000 7 commits
    • Guido van Rossum's avatar
      Fast NonRecursiveMutex support by Yakov Markovitch, markovitch@iso.ru, · 706262bd
      Guido van Rossum authored
      who wrote:
      
      Here's the new version of thread_nt.h.  More particular, there is a
      new version of thread lock that uses kernel object (e.g. semaphore)
      only in case of contention; in other case it simply uses interlocked
      functions, which are faster by the order of magnitude.  It doesn't
      make much difference without threads present, but as soon as thread
      machinery initialised and (mostly) the interpreter global lock is on,
      difference becomes tremendous.  I've included a small script, which
      initialises threads and launches pystone.  With original thread_nt.h,
      Pystone results with initialised threads are twofold worse then w/o
      threads.  With the new version, only 10% worse.  I have used this
      patch for about 6 months (with threaded and non-threaded
      applications).  It works remarkably well (though I'd desperately
      prefer Python was free-threaded; I hope, it will soon).
      706262bd
    • Guido van Rossum's avatar
      When the UTF-8 conversion to Unicode fails, return an 8-bit string · 69529ad0
      Guido van Rossum authored
      instead.  This seems more robust than returning an Unicode string with
      some unconverted charcters in it.
      
      This still doesn't support getting truly binary data out of Tcl, since
      we look for the trailing null byte; but the old (pre-Unicode) code did
      this too, so apparently there's no need.  (Plus, I really don't feel
      like finding out how Tcl deals with this in each version.)
      69529ad0
    • Guido van Rossum's avatar
      Mark Hammond should get his act into gear (his words :-). Zero length · 03e29f1a
      Guido van Rossum authored
      strings _are_ valid!
      03e29f1a
    • Jack Jansen's avatar
      301f3f6b
    • Guido van Rossum's avatar
      Two changes to improve (I hope) Unicode support. · 990f5c6c
      Guido van Rossum authored
      1. In Tcl 8.2 and later, use Tcl_NewUnicodeObj() when passing a Python
      Unicode object rather than going through UTF-8.  (This function
      doesn't exist in Tcl 8.1, so there the original UTF-8 code is still
      used; in Tcl 8.0 there is no support for Unicode.)  This assumes that
      Tcl_UniChar is the same thing as Py_UNICODE; a run-time error is
      issued if this is not the case.
      
      2. In Tcl 8.1 and later (i.e., whenever Tcl supports Unicode), when a
      string returned from Tcl contains bytes with the top bit set, we
      assume it is encoded in UTF-8, and decode it into a Unicode string
      object.
      
      Notes:
      
      - Passing Unicode strings to Tcl 8.0 does not do the right thing; this
      isn't worth fixing.
      
      - When passing an 8-bit string to Tcl 8.1 or later that has bytes with
      the top bit set, Tcl tries to interpret it as UTF-8; it seems to fall
      back on Latin-1 for non-UTF-8 bytes.  I'm not sure what to do about
      this besides telling the user to disambiguate such strings by
      converting them to Unicode (forcing the user to be explicit about the
      encoding).
      
      - Obviously it won't be possible to get binary data out of Tk this
      way.  Do we need that ability?  How to do it?
      990f5c6c
    • Guido van Rossum's avatar
      cc229ea7
    • Guido van Rossum's avatar
      49517821
  5. 03 May, 2000 10 commits