Commit Graph

131 Commits

Author SHA1 Message Date
Tim Peters d674e17e96 SF patch 499062: Minor typo in test_generators.py.
There's no actual patch there.  It's an objection that Guido's example
doesn't actually generator "leaves", so change the comment that says
it does.
2002-03-10 07:59:13 +00:00
Tim Peters 3caca2326e SF bug #488514: -Qnew needs work
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>.
2001-12-06 06:23:26 +00:00
Tim Peters a0a6222509 Teach regrtest how to pass on doctest failure msgs. This is done via a
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).
2001-09-09 06:12:01 +00:00
Tim Peters 5d2b77cf31 Make dir() wordier (see the new docstring). The new behavior is a mixed
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.
2001-09-03 05:47:38 +00:00
Guido van Rossum 297abadc6b The change of type(None).__name__ from 'None' to 'NoneType' broke this
test in a trivial way.  Fixed.
2001-08-16 08:32:39 +00:00
Tim Peters e5614630fb Move one of the tests into the "PEP 255" section, to reflect a change in
the PEP.
2001-08-15 04:41:19 +00:00
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