summaryrefslogtreecommitdiffstats
path: root/Lib/test/test_generators.py
Commit message (Collapse)AuthorAgeFilesLines
* Whitespace normalization.Tim Peters2005-12-251-1/+1
|
* Improve test coverage. Hope the test_file changes work the same on windows.Neal Norwitz2005-11-271-0/+5
|
* Revert previous checkin:Neal Norwitz2005-10-221-1/+1
| | | | | | According to Jeremy, the comment only made sense when the yield was disallowed. Now it's testing that the yield is allowed, so it's not bad and the outer finally is irrelevant.
* Add comment lost from AST mergeNeal Norwitz2005-10-211-1/+1
|
* Merge ast-branch to headJeremy Hylton2005-10-201-1/+1
| | | | | | | | | | This change implements a new bytecode compiler, based on a transformation of the parse tree to an abstract syntax defined in Parser/Python.asdl. The compiler implementation is not complete, but it is in stable enough shape to run the entire test suite excepting two disabled tests.
* Whitespace normalization (via reindent.py).Tim Peters2005-08-261-3/+3
|
* [ 1113421 ] New tutorial tests in test_generators.pyGeorg Brandl2005-08-241-0/+78
|
* Whitespace normalization (ran reindent.py over the whole tree).Tim Peters2005-08-071-10/+10
|
* PEP 342 implementation. Per Guido's comments, the generator throw()Phillip J. Eby2005-08-021-15/+261
| | | | | method still needs to support string exceptions, and allow None for the third argument. Documentation updates are needed, too.
* DocTestFinder._find(): for tests derived from a module __test__ global,Tim Peters2004-09-131-6/+6
| | | | | doctest always promised to stick "__test__" in the name. That got broken. Now it's fixed again.
* Removed old "if 0:" block for leak detection; wouldn't work anymore anyway.Tim Peters2004-08-271-8/+1
|
* Don't really need ellipsis doctests for the syntax errors, becauseTim Peters2004-08-271-12/+12
| | | | | | this module imports itself explicitly from test (so the "file names" current doctest synthesizes for examples don't vary depending on how test_generators is run).
* Fixed 6 failures due to doctest changes.Tim Peters2004-08-271-16/+16
|
* Fixed doctest error (wrong prompts)Edward Loper2004-08-091-3/+3
|
* Replace backticks with repr() or "%r"Walter Dörwald2004-02-121-1/+1
| | | | From SF patch #852334.
* This test depends on the exact ordering produced by the WichmannHillRaymond Hettinger2002-12-301-3/+3
| | | | | random number generator. Altered it a bit to use the old generator and restore the test.
* Add tests for weakref support for generator-iterators.Fred Drake2002-08-091-1/+27
| | | | Part of fixing SF bug #591704.
* Get rid of relative imports in all unittests. Now anything thatBarry Warsaw2002-07-231-1/+3
| | | | | | | | | | | imports e.g. test_support must do so using an absolute package name such as "import test.test_support" or "from test import test_support". This also updates the README in Lib/test, and gets rid of the duplicate data dirctory in Lib/test/data (replaced by Lib/email/test/data). Now Tim and Jack can have at it. :)
* Whitespace normalization.Tim Peters2002-07-161-1/+1
|
* SF bug 567538: Generator can crash the interpreter (Finn Bock).Guido van Rossum2002-06-121-0/+20
| | | | | | | | | | 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.
* Add the 'bool' type and its values 'False' and 'True', as described inGuido van Rossum2002-04-031-12/+12
| | | | | | | | | | | | | 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.
* Remove some now-obsolete generator future statements.Tim Peters2002-04-011-2/+0
| | | | | I left the email pkg alone; I'm not sure how Barry would like to handle that.
* SF patch 499062: Minor typo in test_generators.py.Tim Peters2002-03-101-1/+1
| | | | | | 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.
* SF bug #488514: -Qnew needs workTim Peters2001-12-061-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>.
* Teach regrtest how to pass on doctest failure msgs. This is done via aTim Peters2001-09-091-5/+5
| | | | | | | | | | | 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).
* Make dir() wordier (see the new docstring). The new behavior is a mixedTim Peters2001-09-031-7/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* The change of type(None).__name__ from 'None' to 'NoneType' broke thisGuido van Rossum2001-08-161-2/+2
| | | | test in a trivial way. Fixed.
* Move one of the tests into the "PEP 255" section, to reflect a change inTim Peters2001-08-151-12/+15
| | | | the PEP.
* The message accompanying the TypeError exception on a readonlyGuido van Rossum2001-08-101-1/+1
| | | | attribute changed again.
* Merge of descr-branch back into trunk.Tim Peters2001-08-021-2/+8
|
* Part way to allowing "from __future__ import generators" to communicateTim Peters2001-07-161-0/+2
| | | | | | | | | | 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.
* Having fun on my own time: quicker flat_conjoin; Knights Tour solverTim Peters2001-07-131-113/+123
| | | | simplified and generalized to rectangular boards.
* Remove the last remnants of the hacks to worm around leaks.Tim Peters2001-07-121-12/+3
|
* Repair flawed example.Tim Peters2001-07-121-1/+1
|
* Remove now-unnecessary "from __future__ import nested_scopes" stmts.Tim Peters2001-07-121-2/+0
|
* Remove reference cycle breaking code. The GC now takes care of it.Neil Schemenauer2001-07-121-7/+1
|
* Added a non-recursive implementation of conjoin(), and a Knight's Tourunknown2001-07-041-2/+291
| | | | | | | | | | | | 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!).
* A clever union-find implementation from c.l.py, due to David Eppstein.Tim Peters2001-07-021-0/+77
| | | | | This is another one that leaks memory without an explict clear! Time to bite this bullet.
* Derive an industrial-strength conjoin() via cross-recursion loop unrolling,Tim Peters2001-06-301-9/+83
| | | | and fiddle the conjoin tests to exercise all the new possible paths.
* Added a simple but general backtracking generator (conjoin), and a coupleTim Peters2001-06-291-1/+162
| | | | | | | | | 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.
* Another "if 0:" hack, this time to complain about otherwise invisibleTim Peters2001-06-281-0/+33
| | | | | | "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.
* This no longer leaks memory when run in an infinite loop. However,Tim Peters2001-06-271-81/+58
| | | | | | | | | | | | | | | | | | | | | 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.
* gen_getattr: make the gi_running and gi_frame members discoverable (butTim Peters2001-06-261-2/+22
| | | | not writable -- too dangerous!) from Python code.
* SF bug #436207: "if 0: yield x" is ignored.Tim Peters2001-06-261-7/+128
| | | | Not anymore <wink>. Pure hack. Doesn't fix any other "if 0:" glitches.
* Teach the types module about generators. Thanks to James Althoff on theTim Peters2001-06-251-0/+20
| | | | Iterators list for bringing it up!
* Repair indentation in comment.Tim Peters2001-06-251-2/+9
| | | | Add a temporary driver to help track down remaining leak(s).
* Added a "generate k-combinations of a list" example posted to c.l.py.Tim Peters2001-06-241-1/+49
|
* New tests to provoke SyntaxErrors unique to generators. Minor fiddlingTim Peters2001-06-241-6/+85
| | | | of other tests.
* Another variant of the 2-3-5 test, mixing generators with a LazyList class.Tim Peters2001-06-241-0/+37
| | | | | | | 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.
* More tests.Tim Peters2001-06-241-1/+68
|
generated by cgit v0.12 at 2025-01-15 05:34:54 (GMT)