Commit Graph

8 Commits

Author SHA1 Message Date
Guido van Rossum e2a383d062 Rip out 'long' and 'L'-suffixed integer literals.
(Rough first cut.)
2007-01-15 16:59:06 +00:00
Guido van Rossum 47b9ff6ba1 Restructure comparison dramatically. There is no longer a default
*ordering* between objects; there is only a default equality test
(defined by an object being equal to itself only).  Read the comment
in object.c.  The current implementation never uses a three-way
comparison to compute a rich comparison, but it does use a rich
comparison to compute a three-way comparison.  I'm not quite done
ripping out all the calls to PyObject_Compare/Cmp, or replacing
tp_compare implementations with tp_richcompare implementations;
but much of that has happened (to make most unit tests pass).

The following tests still fail, because I need help deciding
or understanding:

test_codeop -- depends on comparing code objects
test_datetime -- need Tim Peters' opinion
test_marshal -- depends on comparing code objects
test_mutants -- need help understanding it

The problem with test_codeop and test_marshal is this: these tests
compare two different code objects and expect them to be equal.
Is that still a feature we'd like to support?  I've temporarily
removed the comparison and hash code from code objects, so they
use the default (equality by pointer only) comparison.

For the other two tests, run them to see for yourself.
(There may be more failing test with "-u all".)

A general problem with getting lots of these tests to pass is
the reality that for object types that have a natural total ordering,
implementing __cmp__ is much more convenient than implementing
__eq__, __ne__, __lt__, and so on.  Should we go back to allowing
__cmp__ to provide a total ordering?  Should we provide some other
way to implement rich comparison with a single method override?
Alex proposed a __key__() method; I've considered a __richcmp__()
method.  Or perhaps __cmp__() just shouldn't be killed off...
2006-08-24 00:41:19 +00:00
Raymond Hettinger b859c070ef SF bug #800796: Difference between hash() and __hash__()
slice(5).__hash__() now raises a TypeError.
2003-09-05 14:27:30 +00:00
Raymond Hettinger 5d2e777787 SF patch #736962: Port tests to unittest (Part 2)
(Contributed by Walter Dörwald.)

* Convert test_slice.py to unittest format
* Expand the test coverage.
2003-09-02 01:53:01 +00:00
Michael W. Hudson 173f11da5d Some days, I think my comment of
/* this is harder to get right than you might think */

angered some God somewhere.  After noticing

    >>> range(5000000)[slice(96360, None, 439)]
    []

I found that my cute test for the slice being empty failed due to
overflow.  Fixed, and added simple test (not the above!).
2002-11-05 15:28:51 +00:00
Tim Peters 469cdad822 Whitespace normalization. 2002-08-08 20:19:19 +00:00
Barry Warsaw 04f357cffe Get rid of relative imports in all unittests. Now anything that
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. :)
2002-07-23 19:04:11 +00:00
Michael W. Hudson f0d777c56b A few days ago, Guido said (in the thread "[Python-Dev] Python
version of PySlice_GetIndicesEx"):

> OK.  Michael, if you want to check in indices(), go ahead.

Then I did what was needed, but didn't check it in.  Here it is.
2002-07-19 15:47:06 +00:00