Commit Graph

75 Commits

Author SHA1 Message Date
Guido van Rossum 61cf780b6d The message accompanying the TypeError exception on a readonly
attribute changed again.
2001-08-10 21:25:24 +00:00
Tim Peters 6d6c1a35e0 Merge of descr-branch back into trunk. 2001-08-02 04:15:00 +00:00
Tim Peters 5ba5866281 Part way to allowing "from __future__ import generators" to communicate
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.
2001-07-16 02:29:45 +00:00
Tim Peters 9a8c8e270b Having fun on my own time: quicker flat_conjoin; Knights Tour solver
simplified and generalized to rectangular boards.
2001-07-13 09:12:12 +00:00
Tim Peters a1d545523d Remove the last remnants of the hacks to worm around leaks. 2001-07-12 22:55:42 +00:00
Tim Peters 3446365c37 Repair flawed example. 2001-07-12 22:43:41 +00:00
Tim Peters c4889c496a Remove now-unnecessary "from __future__ import nested_scopes" stmts. 2001-07-12 22:36:02 +00:00
Neil Schemenauer b20e9dbf89 Remove reference cycle breaking code. The GC now takes care of it. 2001-07-12 13:26:41 +00:00
unknown 31569561fd Added a non-recursive implementation of conjoin(), and a Knight's Tour
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!).
2001-07-04 22:11:22 +00:00
Tim Peters 353026663c A clever union-find implementation from c.l.py, due to David Eppstein.
This is another one that leaks memory without an explict clear!  Time to
bite this bullet.
2001-07-02 01:38:33 +00:00
Tim Peters c468fd28b6 Derive an industrial-strength conjoin() via cross-recursion loop unrolling,
and fiddle the conjoin tests to exercise all the new possible paths.
2001-06-30 07:29:44 +00:00
Tim Peters be4f0a7748 Added a simple but general backtracking generator (conjoin), and a couple
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.
2001-06-29 02:41:16 +00:00
Tim Peters 08a898f85d Another "if 0:" hack, this time to complain about otherwise invisible
"return expr" instances in generators (which latter may be generators
due to otherwise invisible "yield" stmts hiding in "if 0" blocks).
This was fun the first time, but this has gotten truly ugly now.
2001-06-28 01:52:22 +00:00
Tim Peters f6ed0740a8 This no longer leaks memory when run in an infinite loop. However,
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.
2001-06-27 07:17:57 +00:00
Tim Peters e77f2e2798 gen_getattr: make the gi_running and gi_frame members discoverable (but
not writable -- too dangerous!) from Python code.
2001-06-26 22:24:51 +00:00
Tim Peters b6c3ceae79 SF bug #436207: "if 0: yield x" is ignored.
Not anymore <wink>.  Pure hack.  Doesn't fix any other "if 0:" glitches.
2001-06-26 03:36:28 +00:00
Tim Peters 3e7b1a04a0 Teach the types module about generators. Thanks to James Althoff on the
Iterators list for bringing it up!
2001-06-25 19:46:25 +00:00
Tim Peters 2106ef0222 Repair indentation in comment.
Add a temporary driver to help track down remaining leak(s).
2001-06-25 01:30:12 +00:00
Tim Peters b2bc6a93df Added a "generate k-combinations of a list" example posted to c.l.py. 2001-06-24 10:14:27 +00:00
Tim Peters ea2e97a08a New tests to provoke SyntaxErrors unique to generators. Minor fiddling
of other tests.
2001-06-24 07:10:02 +00:00
Tim Peters ee30927b45 Another variant of the 2-3-5 test, mixing generators with a LazyList class.
Good news:  Some of this stuff is pretty sophisticated (read nuts), and
I haven't bumped into a bug yet.
Bad news:  If I run the doctest in an infinite loop, memory is clearly
leaking.
2001-06-24 05:47:06 +00:00
Tim Peters b9e9ff1288 More tests. 2001-06-24 03:44:52 +00:00
Tim Peters 0f9da0acde Add a recursive Sieve of Eratosthenes prime generator. Not practical,
but it's a heck of a good generator exerciser (think about it <wink>).
2001-06-23 21:01:47 +00:00
Tim Peters 6ba5f79674 Add all the examples from PEP 255, and a few email examples. 2001-06-23 20:45:43 +00:00
Tim Peters 1def351b45 New std test for generators, initially populated with doctests NeilS put
together.
2001-06-23 20:27:04 +00:00