- 12 Haz, 2002 1 kayıt (commit)
-
-
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.
-
- 03 Nis, 2002 1 kayıt (commit)
-
-
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.
-
- 01 Nis, 2002 1 kayıt (commit)
-
-
Tim Peters yazdı
I left the email pkg alone; I'm not sure how Barry would like to handle that.
-
- 10 Mar, 2002 1 kayıt (commit)
-
-
Tim Peters yazdı
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.
-
- 06 Ara, 2001 1 kayıt (commit)
-
-
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>.
-
- 09 Eyl, 2001 1 kayıt (commit)
-
-
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).
-
- 03 Eyl, 2001 1 kayıt (commit)
-
-
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.
-
- 16 Agu, 2001 1 kayıt (commit)
-
-
Guido van Rossum yazdı
test in a trivial way. Fixed.
-
- 15 Agu, 2001 1 kayıt (commit)
-
-
Tim Peters yazdı
the PEP.
-
- 10 Agu, 2001 1 kayıt (commit)
-
-
Guido van Rossum yazdı
attribute changed again.
-
- 02 Agu, 2001 1 kayıt (commit)
-
-
Tim Peters yazdı
-
- 16 Tem, 2001 1 kayıt (commit)
-
-
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.
-
- 13 Tem, 2001 1 kayıt (commit)
-
-
Tim Peters yazdı
simplified and generalized to rectangular boards.
-
- 12 Tem, 2001 4 kayıt (commit)
-
-
Tim Peters yazdı
-
Tim Peters yazdı
-
Tim Peters yazdı
-
Neil Schemenauer yazdı
-
- 04 Tem, 2001 1 kayıt (commit)
-
-
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!).
-
- 02 Tem, 2001 1 kayıt (commit)
-
-
Tim Peters yazdı
This is another one that leaks memory without an explict clear! Time to bite this bullet.
-
- 30 Haz, 2001 1 kayıt (commit)
-
-
Tim Peters yazdı
and fiddle the conjoin tests to exercise all the new possible paths.
-
- 29 Haz, 2001 1 kayıt (commit)
-
-
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.
-
- 28 Haz, 2001 1 kayıt (commit)
-
-
Tim Peters yazdı
"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.
-
- 27 Haz, 2001 1 kayıt (commit)
-
-
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.
-
- 26 Haz, 2001 2 kayıt (commit)
-
-
Tim Peters yazdı
not writable -- too dangerous!) from Python code.
-
Tim Peters yazdı
Not anymore <wink>. Pure hack. Doesn't fix any other "if 0:" glitches.
-
- 25 Haz, 2001 2 kayıt (commit)
-
-
Tim Peters yazdı
Iterators list for bringing it up!
-
Tim Peters yazdı
Add a temporary driver to help track down remaining leak(s).
-
- 24 Haz, 2001 4 kayıt (commit)
-
-
Tim Peters yazdı
-
Tim Peters yazdı
of other tests.
-
Tim Peters yazdı
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.
-
Tim Peters yazdı
-
- 23 Haz, 2001 3 kayıt (commit)
-
-
Tim Peters yazdı
but it's a heck of a good generator exerciser (think about it <wink>).
-
Tim Peters yazdı
-
Tim Peters yazdı
together.
-