- 13 May, 2001 1 commit
-
-
Tim Peters authored
The comment following used to say: /* We use ~hash instead of hash, as degenerate hash functions, such as for ints <sigh>, can have lots of leading zeros. It's not really a performance risk, but better safe than sorry. 12-Dec-00 tim: so ~hash produces lots of leading ones instead -- what's the gain? */ That is, there was never a good reason for doing it. And to the contrary, as explained on Python-Dev last December, it tended to make the *sum* (i + incr) & mask (which is the first table index examined in case of collison) the same "too often" across distinct hashes. Changing to the simpler "i = hash & mask" reduced the number of string-dict collisions (== # number of times we go around the lookup for-loop) from about 6 million to 5 million during a full run of the test suite (these are approximate because the test suite does some random stuff from run to run). The number of collisions in non-string dicts also decreased, but not as dramatically. Note that this may, for a given dict, change the order (wrt previous releases) of entries exposed by .keys(), .values() and .items(). A number of std tests suffered bogus failures as a result. For dicts keyed by small ints, or (less so) by characters, the order is much more likely to be in increasing order of key now; e.g., >>> d = {} >>> for i in range(10): ... d[i] = i ... >>> d {0: 0, 1: 1, 2: 2, 3: 3, 4: 4, 5: 5, 6: 6, 7: 7, 8: 8, 9: 9} >>> Unfortunately. people may latch on to that in small examples and draw a bogus conclusion. test_support.py Moved test_extcall's sortdict() into test_support, made it stronger, and imported sortdict into other std tests that needed it. test_unicode.py Excluced cp875 from the "roundtrip over range(128)" test, because cp875 doesn't have a well-defined inverse for unicode("?", "cp875"). See Python-Dev for excruciating details. Cookie.py Chaged various output functions to sort dicts before building strings from them. test_extcall Fiddled the expected-result file. This remains sensitive to native dict ordering, because, e.g., if there are multiple errors in a keyword-arg dict (and test_extcall sets up many cases like that), the specific error Python complains about first depends on native dict ordering.
-
- 12 May, 2001 7 commits
-
-
Jack Jansen authored
are including Carbon/Carbon.h in stead of the old headers (unless WITHOUT_FRAMEWORKS is defined, as it will be for classic MacPython) and selectively disabling all the stuff that is unneeded in a unix-Python (event handling, etc).
-
Jack Jansen authored
Be more sensible about when to use TARGET_API_MAC_OS8 in stead of !TARGET_API_MAC_CARBON. This should greatly facilitate porting stuff to OSX in its MachO/BSD incarnation.
-
Jack Jansen authored
-
Tim Peters authored
switching from tp_getattr to tp_getattro.
-
Guido van Rossum authored
This now uses the new gotofileline() method defined in FileList.py.
-
Guido van Rossum authored
rather than the idle.py script. This has advantages and disadvantages; the biggest advantage being that we can more easily have an alternative main program.
-
Guido van Rossum authored
Add gotofileline(), a convenience method which I intend to use in a variant. Rename test() to _test().
-
- 11 May, 2001 27 commits
-
-
Tim Peters authored
Allow module getattr and setattr to exploit string interning, via the previously null module object tp_getattro and tp_setattro slots. Yields a very nice speedup for things like random.random and os.path etc.
-
Fred Drake authored
When getting a string buffer for a string we just created, use PyString_AS_STRING() instead of PyString_AsString() to avoid the call overhead and extra type check.
-
Fred Drake authored
-
Fred Drake authored
catch that instead of using a bare except clause.
-
Fred Drake authored
catch that instead of using a bare except clause.
-
Fred Drake authored
exception (for compatibility with old versions of Python).
-
Fred Drake authored
Add a comment elsewhere making clear an assumption in the code.
-
Fred Drake authored
-
Fred Drake authored
-
Fred Drake authored
-
Fred Drake authored
-
Fred Drake authored
-
Fred Drake authored
a bare except clause.
-
Fred Drake authored
so only catch that specific exception.
-
Fred Drake authored
-
Fred Drake authored
some stuff around.
-
Fred Drake authored
constants used by other macros from the headers. Conditionalize VREPRINT and VDISCARD; these are not available on HP-UX. This closes bug #417418.
-
Fred Drake authored
-
Fred Drake authored
-
Fred Drake authored
Finish the last set of changes to these files so the conversion does not break.
-
Fred Drake authored
-
Jeremy Hylton authored
For rich comparisons, use instance_getattr2() when possible to avoid the expense of setting an AttributeError. Also intern the name_op[] table and use the interned strings rather than creating a new string and interning it each time through.
-
Fred Drake authored
Remove unused import of "sys". If the file TESTFN exists before we start, try to remove it. Add spaces around the = in some assignments.
-
Tim Peters authored
-
Fred Drake authored
"\begin{classdesc*}{SomeClass}" -- the rendering of \unspecified was identical to \moreargs, so this helps clarify things just a little.
-
Fred Drake authored
excclassdesc environment.
-
Fred Drake authored
class without providing any information about the constructor. This should be used for classes which only exist to act as containers rather than as factories for instances.
-
- 10 May, 2001 5 commits
-
-
Fred Drake authored
useful documentation on the Scrap Manager.
-
Fred Drake authored
-
Tim Peters authored
doesn't know how to do LE, LT, GE, GT. dict_richcompare can't do the latter any faster than dict_compare can. More importantly, for cmp(dict1, dict2), Python *first* tries rich compares with EQ, LT, and GT one at a time, even if the tp_compare slot is defined, and dict_richcompare called dict_compare for the latter two because it couldn't do them itself. The result was a lot of wasted calls to dict_compare. Now dict_richcompare gives up at once the times Python calls it with LT and GT from try_rich_to_3way_compare(), and dict_compare is called only once (when Python gets around to trying the tp_compare slot). Continued mystery: despite that this cut the number of calls to dict_compare approximately in half in test_mutants.py, the latter still runs amazingly slowly. Running under the debugger doesn't show excessive activity in the dict comparison code anymore, so I'm guessing the culprit is somewhere else -- but where? Perhaps in the element (key/value) comparison code? We clearly spend a lot of time figuring out how to compare things.
-
Tim Peters authored
A Mystery: test_mutants ran amazingly slowly even before dictobject.c "got fixed". I don't have a clue as to why. dict comparison was and remains linear-time in the size of the dicts, and test_mutants only tries 100 dict pairs, of size averaging just 50. So "it should" run in less than an eyeblink; but it takes at least a second on this 800MHz box.
-
Tim Peters authored
and wrap the body in try/finally to ensure TESTFN gets cleaned up no matter what.
-