1. 12 Haz, 2002 1 kayıt (commit)
    • Guido van Rossum's avatar
      SF bug 567538: Generator can crash the interpreter (Finn Bock). · c5fe5eb8
      Guido van Rossum yazdı
      This was a simple typo.  Strange that the compiler didn't catch it!
      Instead of WHY_CONTINUE, two tests used CONTINUE_LOOP, which isn't a
      why_code at all, but an opcode; but even though 'why' is declared as
      an enum, comparing it to an int is apparently not even worth a
      warning -- not in gcc, and not in VC++. :-(
      
      Will fix in 2.2 too.
      c5fe5eb8
  2. 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
  3. 01 Nis, 2002 1 kayıt (commit)
  4. 10 Mar, 2002 1 kayıt (commit)
  5. 06 Ara, 2001 1 kayıt (commit)
    • Tim Peters's avatar
      SF bug #488514: -Qnew needs work · 3caca232
      Tim Peters yazdı
      Big Hammer to implement -Qnew as PEP 238 says it should work (a global
      option affecting all instances of "/").
      
      pydebug.h, main.c, pythonrun.c:  define a private _Py_QnewFlag flag, true
      iff -Qnew is passed on the command line.  This should go away (as the
      comments say) when true division becomes The Rule.  This is
      deliberately not exposed to runtime inspection or modification:  it's
      a one-way one-shot switch to pretend you're using Python 3.
      
      ceval.c:  when _Py_QnewFlag is set, treat BINARY_DIVIDE as
      BINARY_TRUE_DIVIDE.
      
      test_{descr, generators, zipfile}.py:  fiddle so these pass under
      -Qnew too.  This was just a matter of s!/!//! in test_generators and
      test_zipfile.  test_descr was trickier, as testbinop() is passed
      assumptions that "/" is the same as calling a "__div__" method; put
      a temporary hack there to call "__truediv__" instead when the method
      name is "__div__" and 1/2 evaluates to 0.5.
      
      Three standard tests still fail under -Qnew (on Windows; somebody
      please try the Linux tests with -Qnew too!  Linux runs a whole bunch
      of tests Windows doesn't):
          test_augassign
          test_class
          test_coercion
      I can't stay awake longer to stare at this (be my guest).  Offhand
      cures weren't obvious, nor was it even obvious that cures are possible
      without major hackery.
      
      Question:  when -Qnew is in effect, should calls to __div__ magically
      change into calls to __truediv__?  See "major hackery" at tail end of
      last paragraph <wink>.
      3caca232
  6. 09 Eyl, 2001 1 kayıt (commit)
    • Tim Peters's avatar
      Teach regrtest how to pass on doctest failure msgs. This is done via a · a0a62225
      Tim Peters yazdı
      horridly inefficient hack in regrtest's Compare class, but it's about as
      clean as can be:  regrtest has to set up the Compare instance before
      importing a test module, and by the time the module *is* imported it's too
      late to change that decision.  The good news is that the more tests we
      convert to unittest and doctest, the less the inefficiency here matters.
      Even now there are few tests with large expected-output files (the new
      cost here is a Python-level call per .write() when there's an expected-
      output file).
      a0a62225
  7. 03 Eyl, 2001 1 kayıt (commit)
    • Tim Peters's avatar
      Make dir() wordier (see the new docstring). The new behavior is a mixed · 5d2b77cf
      Tim Peters yazdı
      bag.  It's clearly wrong for classic classes, at heart because a classic
      class doesn't have a __class__ attribute, and I'm unclear on whether
      that's feature or bug.  I'll repair this once I find out (in the
      meantime, dir() applied to classic classes won't find the base classes,
      while dir() applied to a classic-class instance *will* find the base
      classes but not *their* base classes).
      
      Please give the new dir() a try and see whether you love it or hate it.
      The new dir([]) behavior is something I could come to love.  Here's
      something to hate:
      
      >>> class C:
      ...     pass
      ...
      >>> c = C()
      >>> dir(c)
      ['__doc__', '__module__']
      >>>
      
      The idea that an instance has a __doc__ attribute is jarring (of course
      it's really c.__class__.__doc__ == C.__doc__; likewise for __module__).
      
      OTOH, the code already has too many special cases, and dir(x) doesn't
      have a compelling or clear purpose when x isn't a module.
      5d2b77cf
  8. 16 Agu, 2001 1 kayıt (commit)
  9. 15 Agu, 2001 1 kayıt (commit)
  10. 10 Agu, 2001 1 kayıt (commit)
  11. 02 Agu, 2001 1 kayıt (commit)
  12. 16 Tem, 2001 1 kayıt (commit)
    • Tim Peters's avatar
      Part way to allowing "from __future__ import generators" to communicate · 5ba58662
      Tim Peters yazdı
      that info to code dynamically compiled *by* code compiled with generators
      enabled.  Doesn't yet work because there's still no way to tell the parser
      that "yield" is OK (unlike nested_scopes, the parser has its fingers in
      this too).
      Replaced PyEval_GetNestedScopes by a more-general
      PyEval_MergeCompilerFlags.  Perhaps I should not have?  I doubted it was
      *intended* to be part of the public API, so just did.
      5ba58662
  13. 13 Tem, 2001 1 kayıt (commit)
  14. 12 Tem, 2001 4 kayıt (commit)
  15. 04 Tem, 2001 1 kayıt (commit)
    • unknown's avatar
      Added a non-recursive implementation of conjoin(), and a Knight's Tour · 31569561
      unknown yazdı
      solver.  In conjunction, they easily found a tour of a 200x200 board:
      that's 200**2 == 40,000 levels of backtracking.  Explicitly resumable
      generators allow that to be coded as easily as a recursive solver (easier,
      actually, because different levels can use level-customized algorithms
      without pain), but without blowing the stack.  Indeed, I've never written
      an exhaustive Tour solver in any language before that can handle boards so
      large ("exhaustive" == guaranteed to find a solution if one exists, as
      opposed to probabilistic heuristic approaches; of course, the age of the
      universe may be a blip in the time needed!).
      31569561
  16. 02 Tem, 2001 1 kayıt (commit)
  17. 30 Haz, 2001 1 kayıt (commit)
  18. 29 Haz, 2001 1 kayıt (commit)
    • Tim Peters's avatar
      Added a simple but general backtracking generator (conjoin), and a couple · be4f0a77
      Tim Peters yazdı
      examples of use.  These poke stuff not specifically targeted before, incl.
      recursive local generators relying on nested scopes, ditto but also
      inside class methods and rebinding instance vars, and anonymous
      partially-evaluated generators (the N-Queens solver creates a different
      column-generator for each row -- AFAIK this is my invention, and it's
      really pretty <wink>).  No problems, not even a new leak.
      be4f0a77
  19. 28 Haz, 2001 1 kayıt (commit)
  20. 27 Haz, 2001 1 kayıt (commit)
    • Tim Peters's avatar
      This no longer leaks memory when run in an infinite loop. However, · f6ed0740
      Tim Peters yazdı
      that required explicitly calling LazyList.clear() in the two tests that
      use LazyList (I added a LazyList Fibonacci generator too).
      
      A real bitch:  the extremely inefficient first version of the 2-3-5 test
      *looked* like a slow leak on Win98SE, but it wasn't "really":  it generated
      so many results that the heap grew over 4Mb (tons of frames!  the number
      of frames grows exponentially in that test).  Then Win98SE malloc() starts
      fragmenting address space allocating more and more heaps, and the visible
      memory use grew very slowly while the disk was thrashing like mad.
      Printing fewer results (i.e., keeping the heap burden under 4Mb) made
      that illusion vanish.
      
      Looks like there's no hope for plugging the LazyList leaks automatically
      short of adding frameobjects and genobjects to gc.  OTOH, they're very
      easy to break by hand, and they're the only *kind* of plausibly realistic
      leaks I've been able to provoke.
      
      Dilemma.
      f6ed0740
  21. 26 Haz, 2001 2 kayıt (commit)
  22. 25 Haz, 2001 2 kayıt (commit)
  23. 24 Haz, 2001 4 kayıt (commit)
  24. 23 Haz, 2001 3 kayıt (commit)