1. 03 Jan, 2008 3 commits
  2. 02 Jan, 2008 1 commit
  3. 29 Dec, 2007 1 commit
  4. 24 Dec, 2007 1 commit
  5. 19 Dec, 2007 1 commit
  6. 18 Dec, 2007 4 commits
  7. 15 Dec, 2007 1 commit
  8. 14 Dec, 2007 1 commit
  9. 13 Dec, 2007 2 commits
  10. 10 Dec, 2007 1 commit
  11. 05 Dec, 2007 2 commits
  12. 03 Dec, 2007 1 commit
  13. 01 Dec, 2007 1 commit
  14. 30 Nov, 2007 1 commit
  15. 29 Nov, 2007 2 commits
  16. 25 Nov, 2007 1 commit
  17. 24 Nov, 2007 4 commits
  18. 23 Nov, 2007 3 commits
  19. 22 Nov, 2007 2 commits
  20. 21 Nov, 2007 2 commits
  21. 19 Nov, 2007 3 commits
  22. 15 Nov, 2007 1 commit
  23. 13 Nov, 2007 1 commit
    • Amaury Forgeot d'Arc's avatar
      Backport for issue1265 (pdb bug with "with" statement). · c572dc37
      Amaury Forgeot d'Arc authored
      When an unfinished generator-iterator is garbage collected, PyEval_EvalFrameEx
      is called with a GeneratorExit exception set.  This leads to funny results
      if the sys.settrace function itself makes use of generators.
      A visible effect is that the settrace function is reset to None.
      Another is that the eventual "finally" block of the generator is not called.
      
      It is necessary to save/restore the exception around the call to the trace
      function.
      
      This happens a lot with py3k: isinstance() of an ABCMeta instance runs
          def __instancecheck__(cls, instance):
              """Override for isinstance(instance, cls)."""
              return any(cls.__subclasscheck__(c)
                         for c in {instance.__class__, type(instance)})
      which lets an opened generator expression each time it returns True.
      
      And the problem can be reproduced in 2.5 with pure python code.
      c572dc37