1. 21 Kas, 2002 1 kayıt (commit)
  2. 03 Eki, 2002 1 kayıt (commit)
  3. 14 Agu, 2002 1 kayıt (commit)
  4. 06 Agu, 2002 2 kayıt (commit)
    • Neal Norwitz's avatar
      Make readahead functions static · d8b995f5
      Neal Norwitz yazdı
      d8b995f5
    • Guido van Rossum's avatar
      SF patch 580331 by Oren Tirosh: make file objects their own iterator. · 7a6e9594
      Guido van Rossum yazdı
      For a file f, iter(f) now returns f (unless f is closed), and f.next()
      is similar to f.readline() when EOF is not reached; however, f.next()
      uses a readahead buffer that messes up the file position, so mixing
      f.next() and f.readline() (or other methods) doesn't work right.
      Calling f.seek() drops the readahead buffer, but other operations
      don't.
      
      The real purpose of this change is to reduce the confusion between
      objects and their iterators.  By making a file its own iterator, it's
      made clearer that using the iterator modifies the file object's state
      (in particular the current position).
      
      A nice side effect is that this speeds up "for line in f:" by not
      having to use the xreadlines module.  The f.xreadlines() method is
      still supported for backwards compatibility, though it is the same as
      iter(f) now.
      
      (I made some cosmetic changes to Oren's code, and added a test for
      "file closed" to file_iternext() and file_iter().)
      7a6e9594
  5. 14 Tem, 2002 1 kayıt (commit)
  6. 30 Haz, 2002 1 kayıt (commit)
  7. 13 Haz, 2002 1 kayıt (commit)
  8. 22 May, 2002 1 kayıt (commit)
  9. 27 Nis, 2002 1 kayıt (commit)
    • Tim Peters's avatar
      Repair widespread misuse of _PyString_Resize. Since it's clear people · 5de9842b
      Tim Peters yazdı
      don't understand how this function works, also beefed up the docs.  The
      most common usage error is of this form (often spread out across gotos):
      
      	if (_PyString_Resize(&s, n) < 0) {
      		Py_DECREF(s);
      		s = NULL;
      		goto outtahere;
      	}
      
      The error is that if _PyString_Resize runs out of memory, it automatically
      decrefs the input string object s (which also deallocates it, since its
      refcount must be 1 upon entry), and sets s to NULL.  So if the "if"
      branch ever triggers, it's an error to call Py_DECREF(s):  s is already
      NULL!  A correct way to write the above is the simpler (and intended)
      
      	if (_PyString_Resize(&s, n) < 0)
      		goto outtahere;
      
      Bugfix candidate.
      5de9842b
  10. 21 Nis, 2002 2 kayıt (commit)
    • Tim Peters's avatar
    • Tim Peters's avatar
      Py_UniversalNewlineFread(): Many changes. · 058b141e
      Tim Peters yazdı
      + Continued looping until n bytes in the buffer have been filled, not
        just when n bytes have been read from the file.  This repairs the
        bug that f.readlines() only sucked up the first 8192 bytes of the file
        on Windows when universal newlines was enabled and f was opened in
        U mode (see Python-Dev -- this was the ultimate cause of the
        test_inspect.py failure).
      
      + Changed prototye to take a char* buffer (void* doesn't make much sense).
      
      + Squashed size_t vs int mismatches (in particular, besides the unsigned
        vs signed distinction, size_t may be larger than int).
      
      + Gets out under all error conditions now (it's possible for fread() to
        suffer an error even if it returns a number larger than 0 -- any
        "short read" is an error or EOF condition).
      
      + Rearranged and simplified declarations.
      058b141e
  11. 14 Nis, 2002 1 kayıt (commit)
    • Jack Jansen's avatar
      Mass checkin of universal newline support. · 7b8c7546
      Jack Jansen yazdı
      Highlights: import and friends will understand any of \r, \n and \r\n
      as end of line. Python file input will do the same if you use mode 'U'.
      Everything can be disabled by configuring with --without-universal-newlines.
      
      See PEP278 for details.
      7b8c7546
  12. 12 Nis, 2002 1 kayıt (commit)
  13. 08 Nis, 2002 1 kayıt (commit)
    • Tim Peters's avatar
      SF bug 538827: Python open w/ MSVC6: bad error msgs. · 2ea9111c
      Tim Peters yazdı
      open_the_file:  Some (not all) flavors of Windows set errno to EINVAL
      when passed a syntactically invalid filename.  Python turned that into an
      incomprehensible complaint about the mode string.  Fixed by special-casing
      MSVC.
      2ea9111c
  14. 07 Nis, 2002 1 kayıt (commit)
  15. 03 Nis, 2002 1 kayıt (commit)
    • Guido van Rossum's avatar
      Add the 'bool' type and its values 'False' and 'True', as described in · 77f6a65e
      Guido van Rossum yazdı
      PEP 285.  Everything described in the PEP is here, and there is even
      some documentation.  I had to fix 12 unit tests; all but one of these
      were printing Boolean outcomes that changed from 0/1 to False/True.
      (The exception is test_unicode.py, which did a type(x) == type(y)
      style comparison.  I could've fixed that with a single line using
      issubtype(x, type(y)), but instead chose to be explicit about those
      places where a bool is expected.
      
      Still to do: perhaps more documentation; change standard library
      modules to return False/True from predicates.
      77f6a65e
  16. 01 Nis, 2002 1 kayıt (commit)
  17. 23 Mar, 2002 3 kayıt (commit)
    • Neil Schemenauer's avatar
      Grow the string buffer at a mildly exponential rate for the getc version · 3a204a7e
      Neil Schemenauer yazdı
      of get_line.  This makes test_bufio finish in 1.7 seconds instead of 57
      seconds on my machine (with Py_DEBUG defined).
      
      Also, rename the local variables n1 and n2 to used_v_size and
      total_v_size.
      3a204a7e
    • Tim Peters's avatar
      Give Python a debug-mode pymalloc, much as sketched on Python-Dev. · ddea208b
      Tim Peters yazdı
      When WITH_PYMALLOC is defined, define PYMALLOC_DEBUG to enable the debug
      allocator.  This can be done independent of build type (release or debug).
      A debug build automatically defines PYMALLOC_DEBUG when pymalloc is
      enabled.  It's a detected error to define PYMALLOC_DEBUG when pymalloc
      isn't enabled.
      
      Two debugging entry points defined only under PYMALLOC_DEBUG:
      
      + _PyMalloc_DebugCheckAddress(const void *p) can be used (e.g., from gdb)
        to sanity-check a memory block obtained from pymalloc.  It sprays
        info to stderr (see next) and dies via Py_FatalError if the block is
        detectably damaged.
      
      + _PyMalloc_DebugDumpAddress(const void *p) can be used to spray info
        about a debug memory block to stderr.
      
      A tiny start at implementing "API family" checks isn't good for
      anything yet.
      
      _PyMalloc_DebugRealloc() has been optimized to do little when the new
      size is <= old size.  However, if the new size is larger, it really
      can't call the underlying realloc() routine without either violating its
      contract, or knowing something non-trivial about how the underlying
      realloc() works.  A memcpy is always done in this case.
      
      This was a disaster for (and only) one of the std tests:  test_bufio
      creates single text file lines up to a million characters long.  On
      Windows, fileobject.c's get_line() uses the horridly funky
      getline_via_fgets(), which keeps growing and growing a string object
      hoping to find a newline.  It grew the string object 1000 bytes each
      time, so for a million-character string it took approximately forever
      (I gave up after a few minutes).
      
      So, also:
      
      fileobject.c, getline_via_fgets():  When a single line is outrageously
      long, grow the string object at a mildly exponential rate, instead of
      just 1000 bytes at a time.
      
      That's enough so that a debug-build test_bufio finishes in about 5 seconds
      on my Win98SE box.  I'm curious to try this on Win2K, because it has very
      different memory behavior than Win9X, and test_bufio always took a factor
      of 10 longer to complete on Win2K.  It *could* be that the endless
      reallocs were simply killing it on Win2K even in the release build.
      ddea208b
    • Neil Schemenauer's avatar
  18. 22 Mar, 2002 2 kayıt (commit)
  19. 15 Mar, 2002 1 kayıt (commit)
  20. 12 Mar, 2002 1 kayıt (commit)
    • Tim Peters's avatar
      Change Windows file.truncate() to (a) restore the original file position, · 8f01b680
      Tim Peters yazdı
      and (b) stop trying to prevent file growth.
      
      Beef up the file.truncate() docs.
      
      Change test_largefile.py to stop assuming that f.truncate() moves the
      file pointer to the truncation point, and to verify instead that it leaves
      the file position alone.  Remove the test for what happens when a
      specified size exceeds the original file size (it's ill-defined, according
      to the Single Unix Spec).
      8f01b680
  21. 11 Mar, 2002 1 kayıt (commit)
    • Tim Peters's avatar
      file_truncate(): provide full "large file" support on Windows, by · fb05db2c
      Tim Peters yazdı
      dropping MS's inadequate _chsize() function.  This was inspired by
      SF patch 498109 ("fileobject truncate support for win32"), which I
      rejected.
      
      libstdtypes.tex:  Someone who knows should update the availability
      blurb.  For example, if it's available on Linux, it would be good to
      say so.
      
      test_largefile:  Uncommented the file.truncate() tests, and reworked to
      do more.  The old comment about "permission errors" in the truncation
      tests under Windows was almost certainly due to that the file wasn't open
      for *write* access at this point, so of course MS wouldn't let you
      truncate it.  I'd be appalled if a Unixish system did.
      
      CAUTION:  Someone should run this test on Linux (etc) too.  The
      truncation part was commented out before.  Note that test_largefile isn't
      run by default.
      fb05db2c
  22. 26 Şub, 2002 1 kayıt (commit)
    • Andrew MacIntyre's avatar
      OS/2 EMX port changes (Objects part of patch #450267): · c487439a
      Andrew MacIntyre yazdı
        Objects/
          fileobject.c
          stringobject.c
          unicodeobject.c
      
      This commit doesn't include the cleanup patches for stringobject.c and
      unicodeobject.c which are shown separately in the patch manager.  Those
      patches will be regenerated and applied in a subsequent commit, so as
      to preserve a fallback position (this commit to those files).
      c487439a
  23. 12 Ock, 2002 1 kayıt (commit)
  24. 01 Ock, 2002 1 kayıt (commit)
  25. 30 Kas, 2001 1 kayıt (commit)
  26. 28 Kas, 2001 1 kayıt (commit)
  27. 09 Kas, 2001 3 kayıt (commit)
  28. 31 Eki, 2001 1 kayıt (commit)
    • Michael W. Hudson's avatar
      fix for · e2ec3ebc
      Michael W. Hudson yazdı
      [ #476557 ] Wrong error message for file.write(a, b)
      
      Makes file.write a METH_VARARGS function.
      e2ec3ebc
  29. 23 Eki, 2001 1 kayıt (commit)
    • Guido van Rossum's avatar
      SF patch #474175 (Jay T Miller): file.readinto arg parsing bug · 00ebd46d
      Guido van Rossum yazdı
          The C-code in fileobject.readinto(buffer) which parses
          the arguments assumes that size_t is interchangeable
          with int:
      
      	    size_t ntodo, ndone, nnow;
      
      	    if (f->f_fp == NULL)
      		    return err_closed();
      	    if (!PyArg_Parse(args, "w#", &ptr, &ntodo))
      		    return NULL;
      
          This causes a problem on Alpha / Tru64 / OSF1 v5.1
          where size_t is a long and sizeof(long) != sizeof(int).
      
          The patch I'm proposing declares ntodo as an int.  An
          alternative might be to redefine w# to expect size_t.
      
      [We can't change w# because there are probably third party modules
      relying on it. GvR]
      00ebd46d
  30. 12 Eki, 2001 1 kayıt (commit)
    • Guido van Rossum's avatar
      Band-aid solution to SF bug #470634: readlines() on linux requires 2 ^D's. · 79fd0fca
      Guido van Rossum yazdı
      The problem is that if fread() returns a short count, we attempt
      another fread() the next time through the loop, and apparently glibc
      clears or ignores the eof condition so the second fread() requires
      another ^D to make it see the eof condition.
      
      According to the man page (and the C std, I hope) fread() can only
      return a short count on error or eof.  I'm using that in the band-aid
      solution to avoid calling fread() a second time after a short read.
      
      Note that xreadlines() still has this problem: it calls
      readlines(sizehint) until it gets a zero-length return.  Since
      xreadlines() is mostly used for reading real files, I won't worry
      about this until we get a bug report.
      79fd0fca
  31. 10 Eki, 2001 1 kayıt (commit)
  32. 05 Eki, 2001 1 kayıt (commit)
    • Guido van Rossum's avatar
      Enable GC for new-style instances. This touches lots of files, since · 9475a231
      Guido van Rossum yazdı
      many types were subclassable but had a xxx_dealloc function that
      called PyObject_DEL(self) directly instead of deferring to
      self->ob_type->tp_free(self).  It is permissible to set tp_free in the
      type object directly to _PyObject_Del, for non-GC types, or to
      _PyObject_GC_Del, for GC types.  Still, PyObject_DEL was a tad faster,
      so I'm fearing that our pystone rating is going down again.  I'm not
      sure if doing something like
      
      void xxx_dealloc(PyObject *self)
      {
      	if (PyXxxCheckExact(self))
      		PyObject_DEL(self);
      	else
      		self->ob_type->tp_free(self);
      }
      
      is any faster than always calling the else branch, so I haven't
      attempted that -- however those types whose own dealloc is fancier
      (int, float, unicode) do use this pattern.
      9475a231
  33. 23 Eyl, 2001 1 kayıt (commit)